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1.0  HTTR0DUCT1CN : 


During  the  past  tvo  years  an  extensive  effort  has  been  underway  within 
the  Electrical  and  Systems  Engineering  Department  at  Rensselaer  Polytechnic 
Institute  (RPl)  to  develop  a  fairly  comprehensive  system  for  the  digital  simu¬ 
lation  of  a  wide  variety  of  point-to-point  digital  communication  systems. 

This  effort  has  resulted  in  the  Interactive  Communications  Simulator  (ICS), 
a  flexible,  graphics  oriented,  and  highly  interactive  hardware/software 
system  consisting  of  a  typical  minicomputer  acting  as  host  to  a  fast  peripheral 
array  processor. 

The  ICS  is  resident  at  RPI  while  a  similar  version  has  been  installed  in 
a  compatible  hardware  system  at  the  Digital  Communications  Experimental  Facility 
(DICEF)  at  RADC.  This  system  is  being  employed  both  to  evaluate  existing 
modem  performance  and  to  explore  new  modulation/coding  concepts  appropriate 
for  military,  commercial,  and  space  applications. 

The  purpose  of  the  present  report  is  to  document  the  develojment  and 
present  state  of  this  system  while  indicating  possible  directions  for  future 
enhancements.  In  Section  ?  we  provide  some  general  background  on  the  ICS. 

This  is  followed  by  a  detailed  functional  description  in  Section  3.  The 
overall  software  structure  is  described  in  Section  U  with  additional  details 
on  the  various  interactive  graphics  routines  provided  in  Section  5.  Finally, 
a  brief  description  of  future  enhancement  possibilities  is  provided  in 
Section  6. 

2.0  GENERAL  BACKGROUND: 

Digital  simulation  provides  a  useful  and  effective  adjunct  to  direct 
analytical  evaluation  of  communication  system  performance.  Indeed,  there 
are  situations  where  explicit  performance  evaluation  defies  analysis  and 
results  can  be  obtained  only  through  either  actual  hardware  evalu*-  ‘  :-.i  or 
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digital  simulation.  The  speed  and  flexibility  associated  with  digital  simu¬ 
lation  generally  provides  a  compelling  reason  for  adopting  this  approach. 

Unfortunately,  an  accurate  simulation  of  most  communication  systems  of 
even  moderate  complexity  can  he  terribly  time  consuming  on  present-day 
general  purpose  machines.  This  is  due  to  the  large  number  of  repetitive 
signal  processing  operations  that  must  be  performed  in  order  to  obtain  a 
statistically  valid  measure  of  system  performance.  Recently  a  class  of  fast 
floating-point  array  processors  has  become  available  which  greatly  facilitates 
these  repetitive  signal  processing  operations.  The  use  of  the  word  "array" 
in  this  context  is  intended  to  indicate  a  processor  optimized  for  handling 
large  data  arrays  in  distinction  to  the  large  machines  organized  as  parallel 
arrays  of  independent  processing  elements.  These  array  processors  are  in¬ 
tended  to  be  employed  as  peripheral  floating-point  processors  in  conjunction 
with  a  general-purpose  host  computer  which  provides  overall  system  control. 
This  hardware  configuration  provides  a  unique  opportunity  for  accurate  and 
statistically  meaningful  digital  simulation  of  existing  and  future  communi¬ 
cation  systems. 

The  RPI  developed  ICS  has  exploited  the  potential  of  this  hardware  con¬ 
figuration.  This  has  resulted  in  an  extensive  hardvare/software  system  for 
the  digital  simulation  of  arbitrary  point-to-point  communication  systems. 
While  the  system  can  be  extended  to  include  analog  communications ,  we  will 
be  primarily  interested  in  digital  communication  systems.  This  system  makes 
extensive  use  of  interactive  computer  graphics  and  includes  a  Digital  Equip¬ 
ment  Corporation  (DEC)  PDP-llAO  acting  as  host  to  a  Floating  Point  Systems, 
Inc. ,  AP-120B  floating-point  array  processor.  A  block  diagram  of  the  hard¬ 
ware  configuration  supporting  the  ICS  software  is  illustrated  in  Fig.  1. 


DEC  -II 
Interactive 
Graphics  Display 

Processor  DEC  LA36 


(I.2M  words  each) 

Figure  1 


Hardvare  Configuration  Supporting  Interactive 
Pnmini cations  Simulator  (ICS) 
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The  user  can  configure  a  vide  variety  of  digital  communication  systems 
from  basic  modules  provided  as  system  facilities.  These  facilities  include: 


channel  coders/decoders;  modulators/demodulators  (modems)  for  a  number  of 
modulation  strategies;  receiver  front-end  filtering;  and  various  bit  syn¬ 
chronization  and  phase  tracking  algorithms..  In  addition  to  additive  vhite 
Gaussian  noise  (AWGN)  channels,  the  simulator  includes  the  ability  to  model 
impulsive  noise  channels  as  veil  as  fading-dispersive  channels  typical  of 
say  HF  or  Tropospheric  scatter  channels . 

3.0  FUNCTIONAL  DESCRIPTION  OF  THE  ICS: 

In  this  section  ve  provide  a  complete  functional  description  of  the  TO". 

We  begin  vith  a  discussion  of  the  general  systems  model  and  proceed  to  a 
description  of  the  various  usage  modes  of  the  ICS.  Finally,  ve  discuss  some 
typical  graphical  output  from  the  ICS. 

3.1  SYSTEMS  MODEL: 

A  Block  diagram  of  a  generic  communi cation  system  which  provides  a  model 
for  simulation  software  development  is  illustrated  in  Fig.  2.  The  information 
source  generally  produces  a  discrete  sequence  or  analog  waveform  which  is  to 
be  encoded,  transmitted  over  a  specified  channel,  reconstructed  and  celivered 
to  a  remote  destination  or  information  sink.  In  Fig.  2,  the  purpose  of  the 
source  encoder  is  to  encode  the  source  output,  presumably  in  an  efficient 
fashion,  into  a  binary  sequence  (a^)  for  subsequent  encoding  and  transmission. 
The  source  decoder  at  the  remote  destination  provides  the  inverse  function. 

That  is,  it  employs  the  binary  sequence  {a^}  to  reconstruct  an  approximation 
to  the  source  output.  The  binary  sequence  (a^)  may  differ  from  the  actual 
transmitted  sequence  •[ }  due  to  channel  errors.  This  has  an  obvious  effect  on 
the  accuracy  vith  which  the  source  decoder  can  reconstruct  the  source  output. 

While  source  coding/decoding  schemes  could  easily  be  incorporated  into  the 


Figure  2 

Block  Diagram  of  General  Communication  System 


simulator,  we  have  chosen  not  to  do  so  for  a  variety  of  reasons.  As  a  result, 
ve  assume  that  the  combination  of  source  and  source  encoder  can  be  modeled  as 
a  binary  memoryless  source  as  indicated  in  Pig.  2.  The  major  criterion  of 
system  performance  is  then  the  bit  error  probability  P^,  i.e.,  the  probability 

A 

that  y  .  This  quantity  can  be  evaluated  by  straightforward  Monte-Carlo 
simulation.  We  will  see,  however,  that  there  are  other  modes  of  usage  of  this 
system.  Each  of  the  remaining  elements  in  Fig.  2  will  be  described  in  detail. 
Channel  Encoder 

The  purpose  of  the  channel  encoder  is  to  accept  the  binary  sequence  {a^} 
at  its  input  and  through  the  insertion  of  controlled  redundancy  produce  the 
M-ary  sequence  {x^}  at  its  output.  Generally,  the  encoded  output  sequence  is 
such  that  x^e{0,l,. . . ,M-1} ,  although  in  the  binary  case  it  will  be  convenient 

to  assume  that  xi  =  ±1,  i  =  1,2, .  3oth  block  and  convolutional  channel 

encoding  capabilities  are  provided  in  the  simulator.  In  the  former,  the  binary 
sequence  {a^}  is  segmented  into  blocks  of  size  k  to  which  n-k  redundant  bits 
are  added  to  produce  a  rate  R=k/n  code  measured  in  units  of  information  bits 
per  transmitted  channel  symbol.  There  is  complete  independence  between  blocks. 
Convolutional  codes,  on  the  other  hand,  do  not  impose  a  block  structure  on  the 
input  information  sequence  and  produce  a  sliding  dependency  over  a  span  of  input 
symbols.  The  encoder  can  be  implemented  as  a  shift  register  into  which  infor¬ 
mation  bits  are  shifted  b  at  a  time.  After  each  shift  n  modulo  two  sums  are 
computed  from  the  contents  of  selected  shift  register  stages  .  These  n  modulo 
two  sums  then  constitute  the  encoder  output  sequence  associated  with  a  particu¬ 
lar  branch  of  b  input  information  bits.  The  normalized  code  rate  in  this  case 
is  S=b/n.  Note  that  each  input  information  bit  affects*  [K/b]n  encoder  output 

The  notation  [x]  means  the  largest  integer  not  exceeding  x. 
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symbols  where  K  is  the  length  of  the  shift  register.  The  quantity  K  is  called 

the  constraint  length  of  the  code.  A  typical  K=3,  R=l/2  encoder  is  shown  in 
Fig.  3.  Tabulations  of  good  convolutional  code  constructions  are  available 

for  various  K  and  R  (cf.  [l],  [2],  [19])- 

The  existing  block  and/or  convolutional  codes  are  generally  effective 
in  correcting  random  errors  and  are  seriously  deficient  in  their  ability  to 
correct  burst  errors.  In  several  important  applications,  the  channel  environ¬ 
ments  are  known  to  introduce  burst  errors  due  to  time-correlated  fading,  multi¬ 
path,  co-channel  interference,  jamming,  etc.  There  are  few  constructive  cod¬ 
ing  approaches  for  channels  with  memory.  Indeed,  the  few  existing  approaches 
are  extremely  sensitive  to  channel  modeling  assumptions  which  are  often  gross 
estimates.  In  the  vast  majority  of  existing  systems  the  approach  is  to  employ 
appropriate  interleaving  schemes  in  an  effort  to  make  the  channel  appear  memory¬ 
less.  In  particular,  the  serial  channel  symbol  sequence  {x..}  is  interleaved 
or  scrambled  in  such  a  fashion  that  successive  channel  symbols  are  trans¬ 
mitted  separated  by  many  channel  signaling  intervals.  This  interleaving 
is  generally  quite  effective  in  reducing  the  effect  of  burst  errors  and  allows 
use  of  the  well-developed  classes  of  random  error-correcting  codes.  At  this 
time  an  interleaving  capability  has  not  been  provided  in  the  ICS.  This  is  one 
of  the  capabilities  which  should  be  included  in  any  future  ICS  enhancements 
as  described  in  Section  6. 

Modulator/Transmitter 

The  purpose  of  the  modulator/transmitter  is  to  map  the  channel  encoder 
output  sequence  {x^  (possibly  interleaved)  into  a  waveform  s(t)  suitable 
for  transmission  over  the  channel.  Encoder  outputs  are  presented  to  the 
modulator/transmitter  every  Tg  seconds  producing  a  time-limited  channel  signal¬ 
ing  waveform  which  vanishes  outside  an  interval  of  total  duration  T  seconds. 

8 

The  quantity  Tg  is  called  the  baud  interval,  or  equivalently  fB=l/Ts  is  the 


Figure  3 

Illustration  of  K=3,  R=l/2 
Convolutional  Encoder 


baud  rate.  We  have  found  it  convenient  to  normalize  all  frequency  (time) 
domain  quantities  to  the  baud  rate  (interval).  For  example,  the  bandwidths 
of  frequency  selective  channel  filtering  elements  are  all  normalized  to  fg. 

This  allovs  the  user  the  ability  to  configure  and  execute  a  simulation 
program  independent  of  the  actual  baud  rate.  This  facilitates  user  inter¬ 
action  with  the  communications  simulator  and  provides  simulation  results  in 
a  convenient  parametric  form. 

In  simulating  the  channel  signaling  waveform  s(t)  we  make  extensive  use 
of  complex  notation.  This  allows  simulation  of  a  bandpass  signal  in  terms  of 
its  lowpass  complex  envelope  and  eliminates  the  need  for  simulating  a  high- 
frequency  carrier  component.  Specifically,  we  assume  that  s(t)  can  be 
expressed  as 

s(t)  -  /T  Re{s(t)eJ2lrfct}  .  (!) 

where  f  is  an  assumed  known  carrier  component  and  S(t)  represents  the 
c  . 

complex  envelope  which  can  be  represented  in  the  form 


s(t)  =  sc(t)-  jsg(t)  ,  (2) 

where  s  (t)  and  s  (t)  are  real  quantities  representing  the  inphase  and  quadra- 
ture  (I/Q)  components  respectively.  By  generating  only  the  I/Q  components,  the 
simulator  need  not  be  concerned  with  the  explicit  details  of  the  KF  portions 
of  the  system.  In  particular,  discrete  samples  of  the  I/Q  components  are 
generated  at  equally  spaced  intervals. 
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In  the  construction  of  the  ICS  it  has  proven  sufficient  to  consider  that 
a(t)  can  be  expressed  as 


s(t) 


V? 


1  CCl,iUc(t-iTs-T  }+  JC2,ius(t-iTs-T  >3  e 


(3) 


where  x  and  6  represent  random  timing  epoch  and  carrier  phase  respectively. 

The  receiver  will  be  required  to  estimate  and  track  these  initially  unknown 

quantities.  Here  the  sequences  {C,  .}  and  {  C_  .}  are  determined  from  the 

a,  i 

channel  encoder  output  sequence  (x. },  while  u  (t)  and  u  (t)  are  elementary 

1  c  s 

baseband  signaling  waveforms.  By  appropriate  choice  of  the  mappings  {c  .}  and 

1 11- 

{C„  .},  together  with  the  baseband  signaling  waveforms  u  (t)  and  u  (t).  the 
^  * Tl  .  c  s 

expression  for  s(t)  is  sufficiently  general  to  include  most  known  modulation 
formats.  This  includes:  coherent  binary  phase-shift  keying  (BPSK),  differ¬ 
entially  coherent  phase-shift  keying  (DPSK),  quadrature  phase-shift  keying 
(QPSK),  noncoherent  frequency-shift  keying  (FSK) ,  and  quadrature  amplitude- 
shift  keying  (ftASK).  In  the  case  of  the  offset  or  staggered  quadrature  phase- 
shift  keyin'?  (OQPSK) ,  and  the  constant  envelope  formats  such  as  continuous 
phase  frequency  shift  keying  (CPFSK)  and  the  special  case  of  minimum  shift 
keying  (MSK)  (cf.  [  3], [4]  )  this  formulation  must  be  modified  slightly. 
Specifically,  in  this  case 


s(t)  = 

where  now  the  elementary  baseband  waveforms  are  translated  by  two  baud 
intervals  at  a  time. 


2[ci,iuc(t-: 


2iTs-X  )  +  JC2jius(t-2iTs-T)]e 


(U) 
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In  the  case  of  coherent  BPSK,'  for  example,  ve  have  Cg^  ■  0,ug(t)  -  0 

while  C.  -  x.  (assume  x,  “  -  l)  and  u  (t)  is  equal  to  the  pulse-like  wave- 
1  }1  1  • 

form  * 


u0(t)  =■  1 
=  0 


0<fc?8 

elsewhere. 


(5) 


Similarly,  in  the  case  of  noncoherent  binary  frequency-shift  keyed  (BFSK) 
modulation  it  is  easily  shown  that  C  .  =  cos0.  +  jsinD.  while  C.  = 

i-  I*  1  1  d.  )  J. 

xiC^  Here  {0^}  represents  a  sequence  of  independent  and  identically 
distributed  (i.i.d.  )  phases  uniformly  distributed  on  [-ir,ir].  Without  this 
latter  assumption,  the  phase  could  be  estimated  at  the  receiver  on  the  basis 
of  past  transmissions  thereby  violating  our  assumption  of  noncoherent  reception. 
The  corresponding  baseband  signaling  waveforms  are  given  by 


uc(t)  =  cos(dwt/2)  uQ(t) 

and 

ug(t)  *  sin(Aut/2)  uQ(t) 


(6a) 

(6b) 


where  dw  is  some  integer  multiple  of  2*/Tg  in  order  to  insure  orthogonality 
betveen  transmitted  tones.  Additional  choices  of  {C^  k=l ,2 ,  and  associated 
baseband  pulseshapes  uc(t)  and  ug(t)  are  provided  in  Table  1. 

It  should  be  noted  that  in  constructing  Table  1  ve  have  imposed  the 
constraint 

+  The  pulse  waveform  u^( t )  in  Table  1  has  value  unity  over  the  interval 

t-T  ,T  1  and  zero  elsewhere. 

s  s 
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Table 


Mote:  un(t)  and  u’(t)  defined  in  text. 


/IT  2 

|S(t)|  dt  =•  EaJ  i-1,2 . 


(i-l)T 


(7) 


so  that  E  represents  the  constant  signal  energy  per  channel  signaling  element 
s 

or  baud.  Indeed,  since  the  simulation  is  to  be  performed  digitally  ve  must 
replace  (7)  by 


Hi-1  2 

l  |s(kAT  ) 1  AT  -  E  i  i»l,2,...  (8) 

k=H  ( i-1 )  s  8  S 

where  H  is  the  number  of  samples  per  baud  and  is  under  user  control.  Typical 

choices  are  N=8,  l6,  or  32.  The  quantity  AT  =T  /N  is,  of  course,  the  sampling 

s  s 

period.  Observe  that  (7)  is  indeed  satisfied  for  each  of  the  entries  in 
Table  1. 

The  communications  simulator  then  generates  the  loypass  I/Q  samples 
{s  (kAT  )}  and  {s  (kAT  )}  .  For  example,  in  the  case  of  coherent  BPSK  described 

C  S  S  8 

above  we  have 


s  (kAT  )  =  x./2E  /T  cos6  ;  (i-l)H<k<iH  (9a) 

c  S  1  s  s  — 

while 

ss(kATg)  =  x  /2E  /Tg  sin6  ;  (i-l)H<k<iH  (9b) 


corresponding  to  the  i'th  successive  baud  interval,  i*l,2,...  . 

Finally,  we  should  mention  one  last  function  provided  in  the  modulator/ 
transmitter  module.  In  particular,  any  narrowband  filtering  or  nonlinear 
amplifier  distortion  effects  will  be  simulated  as  part  of  the  modulator/trons- 
mitter.  For  example,  if  h(t)  represents  the  impulse  response  of  a  narrowband 
or  bandpass  filter,  then  it  can  be  expressed  in  the  form 
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h(t)  =  2Re{h(t)ej2*fct} 


(10  ) 


vhere  b(t)=h  (t)  -  jh  (t)  represents  the  baseband  equivalent  impulse  reponse. 
c  s 

Here  b  (t)  and  h  (t)  are  real  lovpass  functions. representing  inphase  and 

C  3 

quadrature  filtering  effects  respectively.  Let  Sg(t )  represent  the  complex 
envelope  at  the  output  of  this  filter  excited  by  s(t)  at  its  input.  That 
is,  s^(t)=s(t)  ©  h(t)  vhere  ©  represents  convolution.  Expressing  sQ(t) 
in  terms  of  its  inphase  and  quadrature  components  according  to 

s'o(t)  =  soe(t)  -  J  s0s(t) 

ve  have 

d  s0c(t)=3c(t)  ®hc(t)-ss(t)®hs(t)  • 

s„  (t)=s  (t)  ®  h  (t)+s  (t)®  h  (t)  , 

which  is  illustrated  more  conveniently  in  Fig.  U.  A  variety  of  filtering 
options  are  available  to  the  user  in  the  ICS.  These  filters  are  implemented 
as  digital  fixters  and  include  such  options  as  linear-phase  finite  impulse 
response  (FIR)  filters  and  a  variety  of  infinite  impulse  response  (HR) 
filters  such  as  maximally -flat  Buttervorth  response  and  Chebysbev  equiripple 
response  filters.  Filter  parameters  such  as  cutoff  frequency  (normalized  to 
the  baud  rate),  roll-off  characteristics,  passband  phase  and  amplitude  char¬ 
acteristics  are  chosen  by  the  user  from  an  appropriately  formatted  menu  list. 
While  it  would  be  possible  to  provide  various  nonlinear  saturation  effects 
associated  with  the  RF  power  amplifier  in  the  modulator /transmitter  module, 
such  a  capability  is  not  present  in  the  ICS  at  this  time. 


(11  ) 

(12a) 

(12b) 


tering  Operation 


Channel 

In  choosing  a  channel  model  for  the  ICS  it  was  important  to  provide  a 
fairly  general  approach  which  encompasses  the  entire  range  of  potential  appli¬ 
cations.  A  useful  channel  model  which  we  feel  satisfies  this  requirement  con¬ 
sists  of  a  three  component  fading  multipath  channel  plus  additive  noise.  In 
particular,  the  fading  multipath  channel  is  assumed  to  consist  of  a  single 
direct  path,  a  specular  multipath  component,  and  a  diffuse  multipath  conpcn 
as  illustrated  in  Fig.  5.  Here  I(t)  represents  the  complex  envelope  of  the 
transmitted  signal  component  which  we  assume  can  he  expressed  in  terms  01  its 
inphase  and  quadrature  components  according  to  s(t)=sc(t)-jss(t).  The  quan¬ 
tities  and  in  Fig.  5  represent  respectively  the  specular  and  diffuse 
signal  energies  normalized  to  the  energy  in  the  direct  path.  These  parameters 
are  under  direct  user  control.  In  addition,  the  user  is  allowed  to  adjust  the 
relative  phase  <)>  of  the  specular  multipath  component  relative  to  the  direct 
path.  Other  parameter  choices  include  the  nominal  differential  delay  and 
the  differential  doppler  fQ  associated  with  the  two  multipath  components. 

The  delay  and  doppler  spreads  about  these  nominal  values  will  he  determined  hy 
choice  of  the  channel  scattering  function  o(t,f)  associated  with  the  diffuse 
multipath  component.  In  this  context,  the  quantity  o(x,f)  dxdf  represents 
the  energy  associated  with  delays  in  the  range  (x,T+dt  )  and  doppler  shifts 
in  the  range  (f,  f+df). 

The  diffuse  multipath  component  has  been  implemented  hy  means  of  the 
tapped  delay  line  model  illustrated  in  Fig.  6.  This  is  a  fairly  general 
model  for  fading  dispersive  channels  under  the  so  called  vide-sense  stationary 
uncorrelated  scattering  (WSSUS)  assumption  (ef,  [5],  [6]).  The  delay  T 

in  Fig.  6  is  assumed  equal  to  the  Nyquist  rate  T=l/W  where  W  is  the  trans¬ 
mitted  signal  bandwidth.  In  practice,  a  sampling  rate  somewhat  higher  than 
this  may  he  desirable  in  some  applications. 
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Over  ill  Block  Diagram  of  Ohnnnel  Model 


The  quantities  g^(t),  i=0,  ±1,...,  -N  in  Fig.  6  represent  tap  gain 
functions  which  are  modeled  as  mutually  independent  complex  zero-mean  wide- 
sense  stationary  Gaussian  processes.  In  the  communications  simulator  we 
have  restricted  all  the  tap  gain  functions  to  possess  second-order  Butter- 
worth  povt-r  spectral  densities  of  the  form  • 


B? 

si(f)  =!-rAr 

B.  +  f 

l 


i=0,±l,  ...,±N 


(13) 


where  B,.  represents  the  3  dB  bandwidth  in  Hz.  Specification  of  the  3  dB 
bandwidths  B^ ,  i=0,  ±1,±2,  . .  .  ,+  N  then  effectively  determines  the  doppler 
as  a  function  of  delay  profile  as  illustrated  in  Fig.  6.  Similarly,  speci¬ 
fication  of  the  multiplying  factors  ,  i=0,±l,  .  ..,±N,  determines  the  delay 

profile.  The  parameters  N,  B^ ,  and  c^,  i=0,±l,  . . . ,£N,  are  specified  by 
the  user.  The  tap  gain  functions  are  then  obtained  as  the  output  of  appro¬ 
priately  defined  digital  filters  excited  by  white  Gaussian  noise  inputs. 

While  other  more  general  doppler-as-a-function-of-delay  profiles  are  easily 
incorporated  into  the  ICS,  we  feel  that  the  approach  described  here  will 
prove  adequate  for  the  intended  applications. 

Note  that  the  channel  model  as  illustrated  in  Fig.  6  includes  provis¬ 
ion  for  an  additive  noise  component.  An  adequate  model  for  a  vide  range  of 
applications,  including  ELF/VU  and  HF,  can  be  represented  as  the  linear 
combination  of  a  low-density  shot  noise  process  and  additive  white  Gaussian 
noise  (AWGN).  That  is,  the  complex  envelope  n(t)  of  the  additive  bandpass 
noise  can  be  expressed  as 

fi(t)  =  y(t )  tf(t)  •  ( lit) 

Here  y(t)  represents  a  complex  low-density  shot  noise  process  while  fc(t) 


18 


represents  complex  WGN  vitb  double-sided  noise  spectral  density  NQ/2  vatts/Hz. 

By  low-density  we  mean  that  the  interarrival  times  of  the  impulses  are  relative¬ 
ly  long  compared  to  typical  impulse  durations.  The  low-density  shot  noise  com¬ 
ponent  y(t)  accounts  for  the  relatively  infrequent  high-level  and  time-resolved 
impulse  noise  hits  due  to  atmospheric  discharge  phenomenon  or  various  contri¬ 
butions  due  to  man-made  noise.  The  Gaussian  noise  component  w(t),  on  the 
other  band,  is  due  to  a  combination  of  front-end  noise  and  the  large  number 
of  low-level  and  overlapping  impulse  hits.  The  latter  contribution  is  ex¬ 
pected  to  exhibit  Gaussian  behavior  from  central  limit  theorem  considerations. 

The  low-density  shot  noise  component  can  be  modeled  as  the  output  of  a 
linear  time-invariant  filter  excited  by  an  amplitude  modulated  impulse  train 
or  point  process  at  its  input.  The  filter  generating  the  complex  low-density 
shot  process  y(t)  is  assumed  to  possess  impulse  response  n(t),  or  equival¬ 
ently  system  transfer  function  H(s).  A  block  diagram  of  the  channel  noise 
model  is  illustrated  in  Fig.  7  .  The  impulse  response  h(t)  will  in  general 
be  complex  possessing  an  inphase  component  hc(t)  and  a  quadrature  component 
hg(t).  As  indicated  in  Fig.  7  ,  the  input  to  the  linear  filter  generating  the 
low-density  shot  noise  component  y(t)  is  u(t),  assumed  to  be  of  the  form 

N(t) 

u(t)  =  l  56  (t-t  )  .  (15) 

i=0 

Here  { u^}  is  a  sequence  of  complex  independent  and  identically  distributed 
(i.i.d. )  random  variables  which  can  be  expressed  in  terms  of  I/Q  components 
according  to 

Uj-  uci  ~-3us^  9  i— 0,1,...  (l6) 
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Jilaal* 


The  process  {N(t),  t>0}  in  (15)  is  a  point  process,  in  particular  a  counting 
process,  whose  event  times  are  described  by  the  sequence  {t^}.  More  specifi¬ 
cally,  {N(t),  t>p)  undergoes  a  unit  Jump  at  each  of  the  event  times  {t^}.  The 
Poisson  process  is  a  good  example  of  a  counting  process.  The  communications 
simulator  possesses  the  ability  to  simulate  stationary  renewal  counting 
processes  possessing  Gamma  distributed  interarrival  times  with  p.d.f. 


v-1 


f(x)  =  x  exp(-x/8)  ;  x>0  , 

r(v)ev 


(17) 


where  V>1  and  the  parameter  £5  is  defined  according  to  g=l/vA  with  A>0  fixed. 
The  quantity  A  represents  the  average  number  of  events  per  unit  time.  This 
quantity  is  specified  by  the  user  in  units  normalized  to  the  baud  duration  Tg 
seconds.  Specification  of  the  two  parameters  v  and  A,  then,  completely 
defines  the  point  process  (N(t),  t^o). 

For  example,  if  V*l,  then 


f(x)  =  Ae  Xx  ;  x>0 


(18) 


This  is  the  exponential  distribution.  In  this  case,  (lJ(t),  t>0)  is  Poisson 
with  A  the  average  number  of  hits  per  unit  time.  Another  special  case  is 
obtained  by  letting  V-*®  while  holding  A  fixed.  The  result  is 


f(x)  =  6 (x-l/A ) 


(19) 
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where  4(*)  is  the  delta  function.  In  this  case,  the  impulses  are  periodic 
with  rate  X  per  unit  time.  By  introducing  the  class  of  driving  point  pro- 
ceses  described  here,  we  have  a  parameterized  impulsive  noise  model  which 
includes  these  tvo  extremes  as  special  cases.  The  class  of  point  processes 
(N(t),  t>0},  and  hence  d(t),  is  easily  generated  on  a  digital  machine. 

We  have  assumed  that  the  I/Q  components{u  .}  and{u  .}  can  be  described  by 

Cl  si 

u^  =  R^  cos  6^  ,  (20a 


u  .  =  R.  sin  9.  ,  (20' 

si  1  1 

with  {R^}  an  i.i.d.  sequence  possessing  common  orobability  density  function 
(p.d.f.)  f  (•)  while  {0.}  is  likewise  an  i.i.d.  sequence  uniformly  distri- 

T  1 

buted  over  [-»,*].  Related  work  [7]-[8]  on  modeling  impulse  noise  phenom¬ 
enon  indicate  that  an  appropriate  choice  of  p.d.f.  f  (•)  is  the  lognormal 

r 

distribution 

f  (R)  =  — r~  exp<-  R-w)2t  ■  R>0  s  (21 

2o2  I 

where  y  and  <~2  are  the  mean  and  variance,  respectively,  of  a  Gaussian  variate 
g  for  which  r  =  e  .  Another  useful  choice  is  the  pover-Rayleigh  distribution 


defined  by 

fr(R}  =  K0"1  exp{-(R/R0)CX)  ;  R>0,  ( 22) 

R0 

where  the  characteristic  exponent  a  lies  in  the  range  0<a<2  and  RQ  is  a  scale 
parameter  to  be  specified.  The  sequence  is  thus  easily  generated  digitally. 

Some  guidance  on  choosing  parameter  values  to  match  observed  impulse  noise 


characteristics  is  provided  in  [7J-[8]. 


The  low-density  shot  noise  process  y(t)  appearing  at  the  output  of 
the  linear  filter  in  response  to  Q(t)  at  its  input  can  be  expressed  as 

y(t)  =  yc(t)-J  yg(t)  ,  fe 3) 

where  the  I/Q  components  y  (t)  and  y  (t)  can  be  generated  according  to 

c  s 

N(t) 

yc(t)  =  l  Ri[hc(t-ti)eos6i-hs(t-ti)sin6i]  ,  ) 

and 

N(t) 

y  (t)  =  F  F.  [h  (t-t.)cos0  +h  (t-t.)sine.]  .  ',24b  ) 

s  is  i  i  c  i  i 

Here  h  (t)  and  h  (t)  are,  as  described  previously,  the  I/Q  components  of  the 
c  s 

complex  impulse  response  function  ii(t).  We  will  assume  that  hc(t)  and  hg't) 
are  both  equal  to  the  same  impulse  response  function  h^ft).  Several  choices 
for  hQ(t)  are  possible.  For  example,  the  simplest  choice  is  the  pulse  wave¬ 
form  of  duration  t  seconds  normalized  to  the  baud  duration  as  illustrated 
c 

in  Fig.  8 .  The  corresponding  impulse  response  is 


hpft)  =  u_1(t)-u_1(t-tc) 


where  u  ^(t)  is  the  unit  step  function 


u_l<t )“ 


t>0 

t<0 


(25) 


(26) 


The  duration  t  is  specified  by  the  user  such  that  t  «1/X  so  that  the  impulse 
c  c 

process  is  truly  low-density.  Other  choices  of  pulse  waveform  available  are 
illustrated  in  Table  2. 

Finally,  the  WGN  component  which  is  added  to  the  low-density  shot  noise 
component  to  complete  the  channel  noise  model  is  described  in  terms  of  its 
I/Q  components  according  to 

w(t)  =  vc(t)-j  Wg(t)  (2T) 

The  components  w^ft)  and  wg(t)  will  be  modeled  as  mutually  independent  zero-mean 


V' 
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Pulse  Type 

Impulse  Response 

yt) 

Unipolar  Pulse 

u_1(t)-u_1(t-tc) 

Exponential  Pulse 

e"atu_1(t) 

Decaying  Sine 

1  “  at  .  §  % 

—  e  sinii)  t  u  -  (t ) 

ID  c  -1 

c 

Decaying  Cosine 

e~a*cos  w  t  u  .  (t) 
c  -1 

System 

Transfer  Function 
H0(s) 


l-e"stc 


white  Gaussian  noise  processes,  each  possessing  double— sided  noise  spectral 
density  Ng/2  watts/Hz.  These  components  are  easily  simulated. 

DenPdulator/Receiver 

The  main  purpose  of  the  demodulator/receiver  function  module  is  to  perform 
data  demodulation  of  the  channel  output  r(t).  That  is,  to  produce  the  sequence 
{r^}  indicated  in  Fig. 2  which  is  applied  as  input  to  the  channel  decoder.  The 
demodulator/receiver  produces  an  output  once  per  baud  interval.  We  have  pur¬ 
posefully  allowed  {r_. }  to  he  a  vector  sequence  to  accommodate  various  scft 
decision  quantization  or  decoding  schemes.  For  example,  in  an  M-ary  system 
the  receiver  might  well  produce  an  ordered  list  of  the  i  largest  outputs 
during  successive  channel  signaling  intervals.  This  is  the  so-called  list- 
of-i  quantization  scheme  [9]  which  provides  a  reasonably  efficient  and  comp¬ 
utationally  effective  means  for  implementing  soft-decision  decoding  in  a  variety 
of  M-ary  signaling  situations. 

The  demodulator/ receiver  module  contains  a  predection  front-end  which 
precedes  the  data  demodulator  and/or  other  portions  of  this  module.  This  pre¬ 
dection  section  is  illustrated  in  Fig.  9  and  consists  of  a  zero-memory  nonlinear 
(ZMNL)  device  sandwiched  between  two  narrowband  filters.  The  filters  are  imple¬ 
mented  as  described  previously  for  the  output  filtering  provided  in  the  modulator/ 
transmitter  module.  A  ZMNL  processing  capability  has  been  provided  in  the  ICS 
to  allow  simulation  of  various  unintentional  RF  saturation  efforts,'  such  as  in 
a  satellite  transponder,  and  intentional  nonlinear  processing,  such  as  might  be 
used  to  mitigate  against  the  effects  of  impulse  noise. 

The  various  ZMNL  processing  schemes  are  generally  of  the  limiting  variety 
and  have  been  implemented  in  the  ICS  as  illustrated  in  Fig.  10.  Here  the  en¬ 
velope  RA(t)  *  /s2  (t)+s*  (t)  of  the  complex  envelope  sn(t)  is  formed  and  passed 
u  0c  Os  u 
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through  an  instantaneous  or  zero-memory  nonlinear  (ZMNl)  device  with  input/output 
characteristic  g[RQ(t)]  depending  only  upon  the  instantaneous  envelope  RQ(t). 

Forming  the  product 

SqU)  =  g[R0(t)]s0(t)  ,  (28) 

we  can  synthesize  a  variety  of  nonlinearities  of  the  limiting  or  saturation  type  by 
appropriate  choice  of  the  function  g(R).  These  nonlinearities  are  all  characterized  by 
the  fact  that  they  depend  upon  the  envelope  and  not  the  inphase  and  quadrature 
components  individually.  For  example,  the  choice  g(R)=l/R  can  easily  be  shown 
to  correspond  to  an  ideal  bandpass  limiter.  The  choice 
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on  the  other  hand,  represents  a  soft  limiter  or  clipper  characteristic .  A 
wide  variety  of  nonlinear  characteristics  are  provided  under  user  control  in 
an  attempt  to  provide  a  realistic  and  yet  computationally  efficient  model 
for  demodulator /receiver  nonlinear  effects. 

It  should  be  noted  that  in  order  to  perform  its  basic  data  demodulation 
function,  the  demodulator /receiver  module  must  perform  a  variety  of  ancillary 
functions.  These  ancillary  functions  include  symbol  synchronization,  phase 
and/or  frequency  tracking,  and  adaptive  symbol  equalization.  In  addition, 
data  symbol  de-interleaving  is  performed  within  the  demodulator/receiver 
module.  It  is  these  ancillary  functions  which  seriously  complicate  the  design 
of  this  function  module.  The  ICS  also  has  the  capability  of  patching  symbol 
synchronization  and  carrier  phase  and/or  frequency  from  transmitter  to  receiver. 
This  facility  is  useful,  for  example,  when  one  would  like  to  isolate  and 
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eliminate  the  various  synchronization  loop  tracking  dynamics  from  consideration. 

It  should  be  noted  that  the  various  synchronization  schemes  are  intimately 

related  to  the  explicit  modulation  strategies  employed.  The  various  menu  trees 

take  this  into  account  so  that,  for  example,  the  user  is  not  allowed  the 

absurd  choice  of  a  carrier  phase  tracking  loop  when  a  noncoherent  modulation 

strategy  has  been  chosen.  Furthermore,  even  for  coherent  systems  the  carrier 

tracking  loop  depends  explicitly  upon  the  nature  of  the  modulation  alphabet. 

tor  example,  the  typical  squaring  operation  which  precedes  a  carrier  tracking 

or  Costas  loop  in  BPSK  systems  effectively  eliminates  the  bi-phase  modulation. 

til 

It  should  be  replaced  by  a  M  order  nonlinearity  in  MPSK  systems  with  appro¬ 
priate  provision  for  resolving  the  resulting  phase  ambiguity. 

In  addition  to  data  demodulators  correspond!  :ig  to  each  of  the  modulation 
strategies  included  in  the  communications  simulator,  appropriate  adaptive  equal¬ 
izer  sub-modules  are  provided.  More  specifically,  for  the  channel  model  de¬ 
scribed  previously,  the  implicit  diversity  inherent  in  the  multipath  spread 
can  be  exploited  only  through  adaptive  equalization.  That  is,  by  resolution 
of  the  various  multipath  components  it  is  possible  to  completely  remove  this 
source  of  intersymbol  interference  (ISI)  and,  more  importantly,  realize  a 
performance  which  is  an  improvement  over  that  obtained  in  the  absence  of  multi- 
path.  The  current  trend  in  high-speed  modem  design  for  fading  dispersive 
channel  environments  is  to  exploit  this  implicit  diversity.  As  a  result,  an 
initial  equalizer  capability  has  been  provided  in  the  communications  simulator. 

At  present  there  are  three  competing  approaches  to  equalization  of  fading 
dispersive  channels.  The  first  makes  use  of  the  Viterbi  algorithm  (VA)  to 
implement  maximum  likelihood  sequence  estimation  on  the  basis  of  an  assumed 
knowledge  of  the  channel  state.  This  scheme  has  been  described  by  Forney  [9] 
and  Proakis  [lO]  among  others.  T3je  second  approach  is  based  upon  decision 
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feedback  equalization  (DFE)  and  has  been  studied  extensively  beginning  with 
the  work  by  Monsen  [ll]-[l3].  The  basic  DFE  structure  is  illustrated  in  Fig. 

11.  The  function  of  the  transversal  filter  in  the  feedback  path  is  to  eliminate 
the  ISI  due  to  previously  decided  symbols  or  "postcursors"  of  the  channels 
impulse  response.  Similarly,  the  function  of  the  linear  filter  in  the  forward 
path  is  to  eliminate  ISI  from  future  or  previously  undecided  symbols,  i.e.  , 
the  "precursors"  of  the  channels  impulse  reponse.  The  third,  and  final  approach 
makes  use  of  a  tapped  delay-line  (TDL)  equalizer  of  fixed  length  to  equalize 
the  effects  of  ISI. 

The  present  version  of  the  ICS  includes  eptions  for  choosing  either  of  the 
three  types  of  equalizer  (VA,  DFE,  or  TDL)  together  with  the  appropriate 
user  protocol  for  choosing  the  corresponding  equalizer  parameters.  At  present, 
we  assume  knowledge  of  the  channel  filtering  characteristics  through  a  "cheater 
line"  which  informs  the  equalizer  of  the  overall  impulse  response  of  the  channel, 
including  any  narrowband  filtering  used  in  either  the  modulator /transmitter  or 
the  demodulator/receiver.  A  possibility  for  future  enhancements  is  to  provide 
an  adaptive  capability  for  determining  and  tracking  the  instantaneous  state. 
Channel  Decoder 

The  charnel  decoder  will  accept  the  sequence  (r  appearing  at  the  output 
of  the  demodulator/receiver  and  through  appropriate  decoding  algorithms  will 
produce  the  output  sequence  {a^}  delivered  to  the  remote  destination.  Here  we 
have  provided  several  decoding  options  depending  upon  whether  block  or  convolu¬ 
tional  codes  are  used.  In  the  latter  case  we  employ  the  VA  (cf.  [lL] ,  [15]) 
for  decoding  arbitrary  convolutional  codes  with  constraint  lengths  in  the  range 
3£K<10.  For  block  codes  we  have  implemented  several  hard-decision  decoders 
using  essentially  table  look-up  techniques.  This  has  included  the  Hamming  (8,b) 
and  the  Golay  (2k, 12)  codes  which  are  typical  choices  in  a  wide  variety  of 
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applications.  In  addition,  we  have  provided  a  fairly  general  soft-decision 
decoding  capability  for  arbitrary  block  codes  using  the  Wolf  algorithm  [l 6],  [20] 
which  resembles  in  many  ways  the  VA.  Use  of  this  decoding  capability  requires 
explicit  knowledge  of  the  code  parity  check  matrix.  For  selected  codes  this 
information  is  stored  in  tables  on  the  host  PDP-llAO.  The  user  then  specifies 
a  code  (e.g.,  the  Golay  [2k,  12)  code)  and  the  appropriate  parity  check  matrix 
is  loaded  with  the  decoder  program. 

3 . 2  OPERATION  OF  THE  ICS: 

The  overall  technical  design  of  the  ICS  has  been  described  in  some  detail 
in  the  preceding  section.  In  this  section  we  describe  the  interactive  use  of 
this  system.  Careful  consideration  has  been  given  to  this  issue  to  allow 
flexible  and  efficient  usage.  Our  general  philosophy  is  that  simulation  should 
be  used  as  an  adjunct  and  not  as  a  substitute  for  analysis.  The  communications 
simulator  has  been  developed  consistent  with  this  philosophy.  While  the  basic 
approach  is  Monte-Carlo  simulation,  every  effort  has  been  made  to  incorporate 
analytical  and  graphical  techniques  where  and  when  appropriate  to  enhance  and 
extend  the  capabilities  of  this  system. 

The  ICS  has  been  designed  to  be  used  in  four  distinct  modes  of  operation. 
In  the  first,  which  we  call  the  DESIGN  mode,  the  user  assembles  a  simulation 
model  in  building-block  fashion  from  basic  function  modules  provided  as  part 
of  the  system.  Appropriate  user  protocols  have  been  provided  to  guide  even 
the  casual  user  through  the  DESIGN  stage.  Specifically,  the  block  diagram  of 
a  general  communications  system  illustrated  in  Fig.  2  is  displayed  on  the 
graphics  CRT.  Using  the  light  pen,  the  user  selects  successive  blocks  and  a 
menu  list  appears  describing  each  of  the  available  options  for  that  functional 
element.  The  user  chooses  from  this  list  by  entering  the  appropriate  keyboard 
response  eventually  creating  a  DESIGN  file  representing  an  executable  simulation 
model  of  a  complete  end-to-end  communications  system.  This  DESIGN  file 


is  suitably  named  and  entered  im-o  the  system  library.  At  this  point  the  user 
can  exit  from  the  DESIGN  mode  or  continue  creating  alternate  executable  DESIGN 
files.  This  is  the  most  straightforward  of  the  four  usage  modes  and  requires 
no  further  elaboration. 

The  second  usage  mode  will  be  called  the  VALIDATION  mode.  Here  the  user 
will  be  allowed  to  interactively  exercise  a  simulation  model  which  has  pre¬ 
viously  been  developed  in  a  DESIGN  session.  The  purpose  of  the  VALIDATION 
sie  will  be  to  allow  the  user  to  verify  a  simulation  model  before  a  committ¬ 
ment  to  time-consuming  Monte-Carlo  simulation.  More  specifically,  the  user 
'ill  be  allowed  to  view  time  waveforms  and/or  frequency  domain  quantities  such 
j'.jwer  spectral  densities,  system  transiVr  functions,  etc.,  at  critical 
points  in  the  system  to  be  simulated.  This  should  enable  the  user  to  verify 
the  ena-to-end  behavior  of  the  simulation  model  for  the  communication  system 
'under  study  or  the  input/output  behavior  of  any  specific  sub-module.  The  user, 
situated  at  the  graphics  terminal,  can  by  either  light  pen  or  keyboard  entry 
view  time  or  frequency  domain  quantities  as  if  a  scopeprobe  was  connected  to 
the  corresponding  point  in  an  actual  communications  system.  We  refer  to  this 
ability  as  the  oCOPEPROBE  concept.  This  capability  of  the  communication  simu¬ 
lator  should  not  be  considered  as  merely  a  procedural  verification  stage  pre¬ 
ceding  an  actual  simulation.  Rather,  we  feel  strongly  that  the  VALIDATION  mode 
can  itself  be  employed  as  a  highly  flexible  and  useful  tool  in  conceptual  commu¬ 
nication  system  studies.  That  is,  by  employing  the  VALIDATION  mode  a  useful 
and  realistic  appreciation  of  actual  system  behavior  can  be  developed.  Such 
an  appreciation  can  often  serve  as  a  useful  adjunct  to  detailed  analysis.  For 
example,  the  effects  c f  various  filtering  operations  can  be  observed  directly, 
degradations  due  to  intersymbol  interference  or  multipath  can  be  assessed 
visually,  etc.  Hard-copy  output  of  graphics  can  be  obtained  using  the  V&rian 


**211  printer/plotter .  Some  typical,  graphical  outputs  are  provided  in  the 
next  section. 

In  order  to  modify  or  otherwise  change  a  simulation  model,  the  user  must 
leave  the  VALIDATION  stage  and  re-enter  the  DESIGN  mode.  Appropriate  editing 
capabilities  have  been  provided  to  allow  flexible  modification  of  previously- 
developed  simulation  models.  At  any  rate,  the  user  is  at  some  point  ready  to 
commit  a  simulation  model  to  extensive  Konte-Carlo  simulation.  It  is  at  thi^> 
point  that  the  user  enters  the  third  stage  which  we  call  the  SIMULATION  mode. 

In  this  mode,  an  executable  DESIGN  file  corresponding  to  a  simulation  model 
must  be  identified  together  with  appropriate  simulation  parameters.  Primary 
interest  is  in  the  evaluation  of  bit  error  nrobability  P  as  a  function  of 

D 

the  quantity  E^/Nq.  Here  E^  represents  the  signal  energy  per  bit  while  N^/2 
represents  the  double-sided  noise  spectral  density  in  watts/Hz.  As  a  result, 
the  important  parameters  to  be  specified  are  both  an  initial  and  final  value 
of  for  which  simulation  results  are  desired  as  well  as  an  increment  in 

Eb/NQ.  In  addition , parameters  such  as  the  number  of  errors  to  be  collected 
for  each  value  of  E^/N^  and  the  maximum  number  of  iterations  must  be  specified. 
These  latter  quantities  are  necessary  in  order  to  insure  statistical  validity 
of  the  results.  The  communications  simulator  will  then  loop  through  the 
specified  range  of  E^/Nq.  This  is  the  only  parameter  for  which  looped  oper¬ 
ation  is  provided  in  the  SIMULATION  mode.  For  other  parameters  it  is  required 
that  an  appropriate  DESIGN  file  representing  a  simulation  model  with  specific 
parameter  choices  has  been  identified  for  subsequent  execution. 

In  the  SIMULATION  mode,  appropriate  data  logging  and  bookkeeping  software 
is  provided  to  allow  tabulation  of  bit  error  histories  and  evaluation  of  bit 
error  probabilities  as  a  function  of  I^/N  .  This  software  is  considered  an 
important  part  of  the  communications  simulator.  In  addition  to  straightforward 
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evaluation  of  cumulative  tit  error  counts ,  other  basic  statistical  outputs  are 
provided.  For  example,  histograms  of  the  interarrival  times  between  bit  errors, 
the  average  duration  of  error  bursts,  etc.  We  feel  that  many  of  these  other 
statistics  derived  from  bit  error  histories  are  useful  in  some  applications 
for  providing  a  more  complete  picture  of  overall  communication  system  perform¬ 
ance.  Finally,  statistical  files  are  created  for  generating  histograms  of 
other  parameters  during  a  SIMULATION  session.  This  includes  histograms  of 
the  additive  channel  noise  (both  amplitude  and  phase),  and  both  the  phase  and 
bit  synchronization  errors. 

The  last  and  final  mode  of  operation  is  called  the  ANALYSIS  mode.  This 
mode  provides  two  basic  functions.  The  primary  function  is  to  pro  ride  the 
graphical  display  interpretation  of  results  obtained  during  a  typical  SIMULATION 
session.  Appropriate  display  drivers  and  associated  software  have  been  provided 
to  allow  results  to  be  displayed  in  a  format  to  allow  easy  interpretation  by 
communication  systems  engineers.  For  example,  a  basic  requirement  is  to  display 
curves  representing  simulated  bit  error  probability  as  a  function  of  E^/N^. 

In  those  cases  where  closed  form  analytical  expressions  or  bounds  on  P  vs. 

E^/Nq  are  available,  these  are  included  as  user  selected  option.  The  user 
protocol  in  the  ANALYSIS  mode  will  provide  guidance  to  the  user  concerning  any 

such  facilities  available  for  the  system  configuration  and/or  parameter 
choices  under  study.  For  example,  fairly  tight  upper  bour.us  are  available 

Ll^] >  [lT]  on  vs.  for  convolutional  codes  in  conjunction  with  .Viterbi 

decoding  and  employing  a  variety  of  modulation  formats  on  the  AWGN  channel. 
Similar  bounds  have  been  derived  [l8]  for  soft-decision  decoding  of  block  codes 
employing  the  Wolf  algorithm .  These  bounds,  for  the  most  part,  neglect  the 
effects  of  narrowband  filterin',  *rj-erfect  phase  and/or  symbol  synchronization. 
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intersymbol  interference,  etc.  Nevertheless,  the  readily  computed  upper  bounds 
axe  useful  in  providing  a  context  or  perspective  in  which  to  assess  the  degrada¬ 
tions  due  to  these  effects.  For  this  reason,  the  ability  to  compute  and  display 
these  idealized  performance  bounds  together  with  results  obtained  by  simulation 
have  been  incorporated  as  a  useful  feature  of  the  ICS. 

In  the  course  of  developing  the  ICS,  we  have  found  it  useful  to  access  the 
computational  and  display  capabilities  associated  with  the  ANALYSIS  mode  on  a 
stand-alone  basis.  For  example,  the  ability  to  compute  and  plot  upper  bounds, 
and  in  some  cases,  actual  theoretical  performance  of  selected  communication 
systems,  has  proven  useful  in  a  number  of  related  system  studies.  As  a  result, 
the  ANALYSIS  mode  has  been  designed  to  allow  dual  entry  thus  providing  a  secondary 
function  as  a  stand-alone  computational  and  display  resource.  The  library  associated 
with  this  mode  can  be  easily  updated  to  provide  an  expanding  analysis  tool 
quite  independent  of  the  simulation  capabilities  associated  with  the  overall 
system. 

A  block  diagram  illustrating  the  overall  software  organization  of  the 
communications  simulator  is  illustrated  in  Fig.  12.  An  optional  introduction 
to  the  system  is  provided  in  the  user  protocol  associated  with  the  MAIN  DRIVER 
program. 

3.3  TYPICAL  GRAPHICAL  OUTPUT: 

In  this  section  we  describe  some  of  the  hard-copy  graphical  output  ob¬ 
tained  with  the  ICS.  We  consider  first  the  time-domain  waveforms  obtainable 
in  the  VALIDATION  mode.  Limited  frequency-domain  graphical  display  and/or 
output  capabilities  axe  available  and  will  be  described  below.  Virtually 
any  time  waveform  can  be  observed  individually  or  in  combination  with  other 
related  waveforms.  The  user  must  first  specify  a  time  or  viewing  window 
consisting  of  a  fixed  number  of  baud.  A  sequent  of  a  waveform  is  then  dis¬ 
played  within  the  viewing  window  and  the  contents  can  be  indexed  through  a 


38 


MAIN  DRIVER 


waveform  file  in  either  fixed  increments  or  continuously  scrolled  through 
a  large  file.  The  scrolling  can  he  stopped  and  restarted  under  keyboard 
control . 

We  have  found  it  convenient  to  classify  time-domain  waveforms  into 
three  broad  categories: 

1.  BASEBAND  Waveforms 

2.  CHANNEL  Waveforms 

3.  SYNCHRONIZATION  Waveforms 

The  BASEBAND  Waveforms  include  all  time-domain  quantities  which  allow  lowpass 
signal  representations  and  are  in  some  sense  synchronous  with  the  baud  rate. 
This  would  include  source  outputs,  source/channel  encoder  and  decoder  outputs, 
and  matched  filter  outputs  sampled  at  the  baud  rate.  By  comparison,  CHANNEL 
waveforms  include  all  time-domain  waveforms  which  require  complex  represen¬ 
tations,  either  in  polar  coordinates  or  in  terms  of  I/Q  components.  Actually, 
the  user  protocol  allows  the  user  to  specify  either  representation.  Frequency- 
domain  plotting  and  display  capabilities  are  available  for  any  CHANNEL  wave¬ 
form.  The  frequency-domain  representation  is  computed  for  the  observed  wave- 
waveforms  appearing  within  the  viewing  window  and  using  a  wide  variety  of 
possible  window  functions.  Detailed  information  on  the  various  window 
options  is  provided  in  the  user  protocol.  Again,  the  frequency-domain  rep¬ 
resentation  can  be  displayed  in  either  polar  or  rectangular  (i.e.  I/Q)  format 
under  user  control.  Finally,  the  last  category  of  SYNCHRONIZATION  waveforms 
include  all  lowpass  waveforms,  generally  not  synchronous  with  the  baud  rate, 
which  can  be  used  to  describe  the  various  adaptive  tracking  loops .  This 
would  include  instantaneous  phase  and/or  bit  timing  errors,  as  well  as  typical 
error  signals  appearing  in  adaptive  equalizer  loops.  The  graphics  driver 
programs  and  logic  are  decidedly  different  for  each  of  these  three  categories 
of  waveforms. 
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Some  typical  BASEBAND  signaling  waveforms  are  illustrated  in  Pigs.  13a 
and  13b  for  a  K=6,  R=l/2  convolutionally  encoded  BPSK  system  on  the  AWGN  channel 
with  E^/NQ=3dB  and  lOdB  respectively.  In  this  case  the  observation  window 
consists  of  approximately  12  baud  and  we  have  made  use  of  a  MULTIPLE  WAVEFORM 
plotting  option.  More  specifically,  while  the  user  can  look  at  any  indi¬ 
vidual  BASEBAND  waveform  in  the  SINGLE  WAVEFORM  plotting  and  display  mode, 
the  ICS  provides  the  capability  of  plotting  certain  logical  combinations  in 
the  MULTIPLE  WAVEFORM  plotting  option.  These  figures  illustrate  the  source 
output  and  Viterbi  decoder  output  in  time  alignment  in  the  left-hand  column 
while  the  encoder  output  and  matched  filter  output  are  in  time  alignment 
along  the  righthand  column.  This  is  a  logical  arrangement  of  multiple  BASE¬ 
BAND  waveforms  and  is  provided  to  the  user  as  a  display  option.  Notice  the 
raw  channel  symbol  errors  that  are  made  at  low  E^/N^  in  making  hard  decisions 
on  the  polarity  of  the  noisy  matched  filter  output.  The  substantial  error 
control  coding  in  this  case  is  impervious  to  these  errors. 

Typical  CHANNEL  signaling  waveforms  are  illustrated  in  Fig.  1^.  The 
waveforms  in  Fig.  1^  correspond  to  a  coherent  BPSK  system  operating  on  the 
AWGN  channel  at  the  relatively  large  value  E^/Np=  20dB,  while  Fig.  lLb  rep¬ 
resents  a  noncoherent  BFSK  system  operating  under  identical  channel  conditions. 
Here  we  again  make  use  of  a  MULTIPLE  WAVEFORM  plotting  capability  with  the 
left-hand  column  associated  with  the  modulator/transmitter  output  s(t)  while 
the  right-hand  column  is  associated  with  the  channel  output  r(t).  Furthermore, 
the  CHANNEL  waveforms  in  this  case  are  plotted  in  polar  coordinates  in  terms 
of  envelope  and  phase.  Similar  plots  in  rectangular  coordinates  using  I/Q 
components  could  have  been  chosen  under  user  control.  Likewise,  individual 
CHANNEL  waveforms  could  have  been  selected  under  the  SINGLE  WAVEFORM  plotting 
and  display  option.  In  this  case,  frequency-domain  representations  could  be 


computed  and  displayed. 


Figure  13 


Typical  Baseband  Signaling  Waveforms 
for  BPSK  Modulation  on 
AWGN  Channel  Employing 
K=6,  R=l/2  Convolutional  Code 
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l>.)  iionconprent,  BrSF,  E^/K  ^  =  20dB 

Figure  1^ 

Typical  Channel  Signaling  Waveforms 
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Finally,  as  described  above,  the  last  category  of  time-domain  signals 
are  SYNCHRONIZATION  waveforms.  Typical  phase  and  bit  timing  errors  are 
illustrated  in  Fig.  15  for  a  coherent  BPSK  system.  While  these  waveforms  are 
plotted  jointly  in  time  alignment,  the  user  has  the  option  of  plotting  either 
waveform  individually  under  the  SINGLE  WAVEFORM  plotting  option.  Similarly,  plots 
of  the  error  signal  in  the  tracking  loop  of  an  adaptive  equalizer  can  be  dis¬ 
played  in  this  category  of  time-domain  waveforms. 

A  number  of  additional  graphical  plotting  and  display  capabilities 
exist  in  the  ANALYSIS  mode.  For  the  most  part,  these  consist  of  accessing, 
formatting,  and  displaying  error  statistics  or  noise  amplitude  probability 
distributions  (APD's)  generated  in  executing  an  appropriate  DESIGN  file  in 
the  SIMULATION  mode.  For  example,  a  DESIGN  file,  representing  a  coherent 
BPSK  system  operating  on  the  AWGN  channel  and  employing  a  K=6,  R=l/2  con¬ 
volutional  code,  was  executed  in  the  SIMULATION  mode  and  both  raw  and  de¬ 
coded  error  statistics  collected.  In  Fig.  16  we  illustrate  the  measured 
symbol  error  probability  Pg  and  the  decoded  bit  error  probability  Pfc. 

The  decoded  bit  error  probability  is  plotted  as  a  function  of  E^/N^  while 
the  symbol  error  probability  is  plotted  as  a  function  of  the  quantity  E  /KQ. 

Here,  Eg  is  the  signal  energy  on  a  per  baud  basis  and  is  related  to  E^ 
according  to  Eg  =  RE^  where  R  is  the  code  rate  (in  this  case  R=l/2). 

Also  included  in  the  respective  plots  in  Tig.  16  is  the  theoretical  symbol 

error  probability  P  and  the  computed  upper  bound  on  P +.  The  simulation 
e  d 

results  compare  favorably  to  these  computed  results.  These  results  provide 
a  complete  picture  of  the  performance  of  the  coded  coherent  BPSK 
system  on  the  AWGN  channel.  The  total  elapsed 

t  Simulation  results  are  plotted  with  crossed  while  computed  results  employ 
open  circles.  The  numbers  along  the  left-hand  margin  of  these  plot? 
respresents  powers  of  10. 
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Figure  1 6 

Plots  of  Symbol  and  Bit  Error  Probability 
for  BPSK  System  Operating  on  AWGN 
Channel  and  Employing  K=6,  R=l/2 
Convolutional  Code  with  Viterbi  Decoding 
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time  to  execute  the  SIMULATION  mode  in  this  case  over  the  range  OdB<£^ /N ^<6dB 
in  steps  of  0.5dB  was  2  hrs.  This  is  significant  when  one  observes  that 
error  events  as  rare  as  one  in  107  have  been  accurately  measured.  Comparable 
simulation  capabilities  would  be  impossible  in  existing  general-purpose 
machines.  Indeed,  it  is  questionable  whether  or  not  such  an  extensive  simu¬ 
lation  would  be  undertaken  in  the  first  place. 

Other  graphical  output  available  in  this  case  would  include:  histograms 
of  the  additive  channel  noise  amplitude  and  phase,  two-dimensional  histograms 
of  the  phase  and  time  synchronization  errors,  and  various  statistics  derived 
from  bit  error  histories  as  described  earlier.  In  the  interests  of  space, 
these  will  not  be  described  here. 

SOFTWARE  DESCRIPTION  : 

The  purpose  of  this  section  is  to  describe  the  basic  structure  of  the 
software  implementing  the  SIMULATION  and  VALIDATION  modes  of  the  ICS.  It  is 
in  these  modes  that  data  is  generated,  processed,  and  results  tabulated. 

In  the  VALIDATION  mode,  the  ICS  performs  a  relatively  short  simulation 
of  a  point-to-point  communication  system  which  has  been  previously  configured 
in  the  DESIGN  mode.  The  number  of  baud  processed  in  this  case  is  typically 
in  the  range  IOC- 500.  Waveform  data  is  extracted  from  the  AP-120B  and 
stored  on  the  PDF- 11/hO  disc  for  later  display  and/or  hard-copy  output  in 
the  ANALYSIS  mode. 

In  the  SIMULATION  mode,  the  ICS  performs  an  extended  Monte-Carlo  simulation 
of  the  configured  system  represented  by  an  executable  DESIGN  file.  Extensive 
error  statistics  are  tabulated  during  this  stage  for  later  access  in  the 
ANALYSIS  mode. 
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4.1  FORTRAN  DRIVER  PROGRAM: 

Each  of  the  communication  system  blocks  is  implemented  by  an  AP-120B 
assembly  language  module.  All  data  generation  and  processing  is  performed 
in  the  AP-120B.  Once  a  complete  system  has  been  designed  by  the  user,  it  is 
the  job  of  the  driver  program  to  select,  load,  and  run  the  various  AP  program 
modules  corresponding  to  the  various  system  components.  The  same  driver  is 
used  for  both  the  SIMULATION  and  VALIDATION  modes.  The  only  difference  is 
the  amount  and  type  of  data  which  is  collected. 

Upon  entering  the  VALIDATION  mode,  the  user  specifies  the  length  of  the 
simulation  and  at  which  points  in  the  system  he  would  like  to  collect  wave¬ 
form  data.  When  the  VALIDATION  run  actually  begins,  the  driver  program  will 
access  the  DESIGN  file  to  determine  which  program  modules  to  load  along  with 
their  associated  simulation  parameters.  After  this,  the  entire  design  file  is 
transferred  to  the  AP-120B  so  that  any  of  the  DESIGN  file  information  may  be 
accessed  by  an  executing  AP  program.  After  the  AP  has  been  loaded,  the  program 
modules  are  exercised  sequentially  with  waveform  data  being  stored  on  the 
PDP-11/40  disc. 

Operation  of  the  driver  during  the  SIMULATION  stage  is  identical  except 
for  the  fact  that  the  system  now  may  perform  a  number  of  simulations  for 
different  values  of  signal-to-noise  ratio.  During  this  mode,  error'  statistics 
rather  than  waveform  data  are  stored  on  disc.  The  data  flows  during  the 
operation  of  the  simulator  are  diagrammed  in  Fig.  17.  The  overall  logic 
flow  of  the  driver  program  is  shown  in  Fig.  18. 

4.2  DATA  STRUCTURES: 

It  is  difficult  to  simulate  a  continuous  data  stream  inside  a  processor 
with  limited  memory,  since  only  a  small  block  of  data  may  be  processed  at  one 
time.  There  are  basically  two  schemes  for  facilitating  this. 
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Figure  17 

Data  Flows  in  Operation  of  the  ICS 


Fi gure  18.1 

Overall  Logic  Flow  of  Driver  Program 
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Figure  18.2 

Overall  Logic  Flow  of  Driver  Program 


Figure  78.3 

Overall  Logic  Flow  of  Driver  Program 
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Figure  18.4 

Overall  Logic  Flow  of  Drive- r  Program 


Figure  18.5 

Overall  Logic  Flow  of  Driver  Program 
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Figure  18.6 

Overall  Logic  Flow  of  Driver  Program 


Figure  18.7 

Overall  Logic  Flow  of  Driver  Program 


Figure  18.8 

Overall  Logic  Flow  of  Driver  Program 


CALCULATE  ERROR 
PROBABILITIES 


In  the  first  scheme,  we  fix  the  data  blocks  and  operate  the  programs  on 
these  various  data  blocks  sequentially.  The  data  blocks  must  also  be  produced 
and/or  refreshed  sequentially  with  this  scheme.  This  method  presents  serious 
difficulties  since  addressing  becomes  complicated  and  programs  which  require 
a  continuous  observation  window  are  not  easily  accommodated. 

In  the  second  scheme  (the  one  presently  employed  in  the  ICS)  the  programs 
operate  on  fixed  blocks  in  memory  and  the  data  stream  is  "slid"  by  the 
program's  "observation  window".  With  this  scheme,  it  is  easy  to  provide  past 
and  future  data  on  either  side  of  the  observation  window  for  programs  that 
have  such  a  requirement.  This  is  necessitated  by  certain  phase  estimation 
and  bit  synchronization  algorithms  or  any  program  module  employing  some  type 
of  memory  (i.e.,  Viterbi  algorithm). 

Consider  the  channel  block  diagram  illustrated  in  Fig.  19.  In  this  diagram, 
IBLK,  IBLK1,  IBLK2 ,  IBLKB,  IBLKB,  IBIKS  and  IBLKM  are  Fortran  variables  which 
are  calculated  by  the  driver  at  run  time.  IBLKR  is  the  run  address  for  the 
receiver  program  and  is  fixed  at  the  top  of  the  'present'  block. 

The  steady  state  mode  of  operation  is  illustrated  in  the  flowchart  in 
Fig.  20.  (We  ignore  the  start  up  mode  since  it  is  not  germane  to  this 
discussion.)  Before  entering  the  flowchart,  we  assume  block  B  has  been 
processed  by  the  receiver  and  we  are  now  ready  to  process  another  block.  At 
this  time  block  A  is  full  of  data  and  block  C  has  been  processed  one  cycle 
earlier. 

The  following  four  steps  are  now  performed: 

1.  blocks  B  and  A  are  slid  (moved)  upward  to  be  congruent  to 
blocks  C  and  B  respectively.  Previous  data  in  block  C  is  written 
over. 

2.  The  transmitter  program  is  exercised  to  fill  block  A  with  data. 
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Figure  19 

Channel  Data  Block  Diagram 
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3.  The  channel  program  is  operated  to  corrupt  the  transmitter  output 
vith  noise. 

1*.  The  receiver  is  again  operated  on  block  B. 

If  intermediate  results  (for  waveform  plots,  etc.)  are  to  be  collected, 
this  information  may  be  accessed  between  the  above  steps  by  a  DMA  transfer 
to  the  host  (and  perhaps  subsequently  to  disc  or  tape). 

Since  the  block  length  (NB  or  NBIT)  is  normally  a  complicated  function  of 
variables  such  as  the  number  of  samples/baud  and  the  code  rate,  it  is  necessary 
to  calculate  run  addresses  and  block  lengths  at  run  time. 

We  normally  allot  the  maximum  data  memory  space  for  each  program  module 
and  then  use  a  portion  of  this  space  during  a  particular  simulation.  Speci¬ 
fically,  consider  the  example  below: 

The  number  of  source  bits  to  be  generated  is  given  by 


where  HS  is  the  number  of  samples  per  baud  and  may  range  from  k  to  32.  Vie 
may  be  required  to  produce  from  16  to  128  source  bits.  Therefore,  we  must 
allocate  at  least  128  memory  locations  for  the  source. 

The  memory  layout  is  shown  in  Fig.  21.  We  have  allotted  38b  memory 
locations  to  the  source.  This  allows  for  storage  of  up  to  3  blocks  of  source 
data.  The  important  point  to  note  here  is  that  the  run  address  (IADRBR)  is 
dynamically  calculated  at  run  time,  allowing  for  greater  flexibility  in  the 
simulation.  The  only  addresses  which  are  fixed  are  the  top  and  bottom  source 
block  boundaries.  All  other  simulator  modules  operate  in  a  similar  fashion. 

U.3  SYSTEM  SOFTWARE  CONNECTION ; 

The  simulator  driver  program  controls  the  A P-  120B  through  the  software 
hierarchy  diagrammed  in  Fig.  22. 

As  the  simulation  evolves,  each  communication  system  module  is  called  in 


turn  by  the  driver  program.  (STEP  l) 


«* - -  1646.  (BOTTOM  OF  SOURCE  BLOCK) 


IADRBR  =  IADRB-NBIT 


IADRB  =<  2029.  (TOP  OF  SOURCE  BLOCK) 


Figure  21 

Dynamic  Addressing  Scheme  in  ICS 
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R.P.I.  INTERACTIVE  COMMUNICATIONS  SIMULATOR 


SOFTWARE  CONNECTION 


Figure  22.1 

ICS  Software  Connection 
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Figure  22,2 

ICS  Software  Connection 
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Each  of  the  individual  module  programs  keep  a  table  of  PDP-11 A 0  disc 
file  names  and  lengths  corresponding  to  the  various  options  implemented  for 
that  system  block.  For  example,  the  XMTR  module  has  a  list  of  files  which 
include  BPSK.LNK  and  BPSK.LNK.  These  are  load  module  files  which  have 
been  prepared  using  APAL  and  APLINK. 

As  the  system  module  program  is  called,  it  is  also  passed  an  option  index 
which  is  originally  derived  from  the  DESIGN  file.  This  option  index  acts  as 
a  pointer  into  the  table  of  file  names. 

Once  a  file  name  has  been  selected,  this  name,  along  with  any  S-PAD  para¬ 
meters  is  passed  to  the  executive  program.  (STEP  2) 

The  executive  program  now  calls  various  PDP-11 Ao  assembly  language  programs 
(STEP  3)  which  load  the  appropriate  files  into  the  AP-120B  (STEP  U)  and  then 
loads  S-PADS  and  runs  the  AP.  (STEP  5). 

1*A  AP-120B  PROGRAM  REQUIREMENTS: 

Although  the  array  processor  program  characteristics  may  vary  considerably, 
depending  on  their  application  in  the  simulator  system,  there  are  certain  uni¬ 
versal  requirements  which  must  be  met  in  order  to  be  consistent  with  the  over¬ 
all  simulator  structure. 

Because  of  the  dynamic  addressing,  each  program  must  have  the  cat  ability 
for  its  input  and  output  data  addresses  to  be  loaded  at  run  time.  Similarly, 
since  the  data  block  length  is  a  variable  which  is  calculated  at  run  time,  it 
must  be  loaded  as  well . 

This  information  can  either  be  passed  directly  through  the  Fortran  call 
by  implicit  use  of  the  SPLO  Go  (S-PAD  load  and  go)  routine  or  through  a  DMA 
to  predetermined  AP  memory  locations.  In  the  latter  case,  the  AP  program 
may  need  to  subsequently  transfer  these  memory  locations  to  S-  PADS  depending 
on  the  structure  and  application  of  the  AP  program. 


5.0  GRAPHICS  SUPPORT  PACKAGE: 

To  provide  the  interactive  graphics  capabilities  of  the  ICS,  a  fairly 
extensive  GRAPHICS  SUPPORT  package  was  developed  and  has  been  in  a  constant 
state  of  evolution.  This  package  consists  of  a  number  of  waveform  plotting 
routines  which  access  general  purpose  graphics  subroutines  which  have  been 
developed  and  are  stored  in  a  Graphics  Library  on  the  PDP-llAo.  The  pur¬ 
pose  of  this  section  then  is  to  provide  an  overview  of  this  GRAPHICS  SUPPORT 
package.  Additional  details,  including  listings,  can  be  found  in  [2k],  [25]. 

5.1  PLOTTING  ROUTINES  : 

In  the  VALIDATION  mode  there  are  six  separate  time-domain  plotting 
programs  as  illustrated  in  Table  3.  The  data  structures  are  such  that  the 
same  basic  algorithm  can  be  used  for  all  six  plotting  schemes.  In  the 
VALIDATION  mode  we  are  interested  in  the  output  of  fourteen  separate  modules. 

These  fourteen  modules  are  divided  into  three  classes,  the  BASEBAND  output, 
the  CHANNEL  output ,  and  the  SYNCHRONIZATION  output  ( see  Table  k) .  Each  of 
these  classes  has  the  option  of  plotting  either  individually,  in  the  SINGLE 
WAVEFORM  plotting  option,  or  in  conjunction  with  other  data  of  the  same 
class,  in  the  MULTIPLE  WAVEFORM  plotting  option. 

The  flowchart  for  the  basic  plotting  algorithm  is  illustrated  in  Fig.  23. 
Each  program  begins  with  a  short  description  of  its  purpose  and  a  list  of  all 
the  object  modules  that  it  is  linked  to.  Every  variable  is  iden*i.ified  and 
its  function  in  the  program  specified.  The  names  of  the  programs  to  be 
linked  to  are  encoded  in  Radix- 50  at  this  point.  The  subroutine  RCHAIN  is 
called  to  determine  whether  or  not  the  program  was  chained  to;  this  function 
is  not  necessary  for  the  operation  of  these  programs,  but  it  must  be  called 
in  order  to  chain  at  the  end  of  the  program.  The  next  phase  involves  clearing 
the  display  processor,  activating  it,  and  preparing  it  to  display  plots  . 


PROGRAM  NAME 

CLASS  PLOTTED 

ANAL2.SAV 

CHANNEL 

ANAL3.SAV 

CHANNEL 

ANAL4.SAV 

BASEBAND 

ANAL5.SAV 

BASEBAND 

ANAL6.SAV 

SYNCHRONIZATION 

ANAL7.SAV 

SYNCHRONIZATION 

Table  3 

Time-Domain  Plotting  Programs 
Used  in  VALIDATION  Mode 
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TYPE 

SINGLE 

MULTIPLE 

SINGLE 

MULTIPLE 

SINGLE 

MULTIPLE 


DEFINE 
DATA  I 
STRUCTURE  j 


/  INPUT- 
/  DATA 
/  PARAK. 


Figure  23.2 

Flowchart  for  plotting  routines 
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A  number  of  variables  are  now  initialized  to  their  default  values.  The 
window  size  is  set  at  either  4  or  7  baud  and  the  record  and  element  pointers 
are  initialized  to  the  first  element  of  the  first  data  record.  The  screen 
is  activated  and  a  menu  of  al  1  the  available  plots  is  listed  on  the  screen. 
When  the  user  makes  a  choice  the  program  branches  to  a  section  of  the  program 
that  will  obtain  the  data  corresponding  to  the  user's  choice.  The  data 
structure  of  the  chosen  module  is  defined,  parameters  related  to  the  data 
such  as  the  length  of  the  data  file,  the  useful  portion  of  the  data  file  , 
etc.  are  read  in  by  the  program.  The  program  then  proceeds  to  call  subroutine 
MSHFT;  a  subroutine  that  creates  a  continuous  data  file,  i.e.  a  file  without 
spaces  or  undesirable  data. 

The  program  is  now  ready  to  utilize  the  Graphics  Library .  The  origin 
of  each  coordinate  system  must  be  established  by  calling  subroutine  ZINIT 
(see  subroutine  ZINIT).  The  X-axis  is  scaled  according  to  the  number  of 

baud  to  be  plotted.  The  Y-axis  is  scaled  on  the  basis  of  the  largest  value 
in  the  data  array.  Negative  values  are  also  taken  into  account  and  their 
absolute  value  is  used  in  determining  the  largest  value  in  the  array.  Both 
scale  factors  are  determined  and  stored  in  the  common  block  SCFILE  (see 
Common  Block  SCFILE).  The  next  two  subroutines  called  make  use  of  these  scale 
factors  and  also  the  maiximum  and  minimum  values  in  the  array  as  they  draw 
the  two  axis  and  a  grid  to  facilitate  viewing.  Finally,  the  data  is  plotted 
as  points  and  interconnecting  lines  are  drawn. 

The  program  now  enters  the  Command  mode,  a  mode  where  the  display  may 
be  altered  until  the  desired  effect  is  achieved  and  a  hard  copy  obtained. 

This  mode  offers  the  user  the  ability  to  exercise  a  maximum  of  5  options. 

After  viewing,  the  program  then  is  chained  back  to  the  ICS  DRIVER  PROGRAM. 


The  Command  Mode 


RECORD  n  -  This  allows  the  user  to  go  to  the  beginning  of  the  nth  data 

record  and  look  at  the  default  number  of  baud  at  the  beginning 
of  that  record.  The  number  of  records  in  the  file  is  printed 
as  a  guide  to  the  user. 

CHANGE  SIZE  -  This  allows  the  user  to  change  the  window  size  from  1  baud 

to  a  maxi  mum  determined  on  the  basis  of  the  number  of  samples 
per  baud  and  the  useful  portion  of  the  data  per  data  record. 

The  maximum  is  printed  as  a  guide  to  the  user. 

SHIFT  WINDOW  -  This  allows  the  user  to  shift  the  window  and  look  at  a  differ¬ 
ent  part  of  the  data  stream.  Since  there  is  a  continuous 
stream  of  data  the  entire  file  may  be  viewed  with  this  command. 
When  the  user  attempts  to  exceed  the  boundaries  of  the  file 
an  error  message  is  printed  warning  the  user  of  the  problem. 

At  present  there  is  no  algorithm  to  determine  shifting  limits, 
but  I  believe  that  one  is  feasible. 

HARD  COPY  -  This  allows  the  user,  through  the  Versatec,  to  make  a  hard  copy 
of  the  display.  Tnis  part  of  the  program  may  also  be  accessed 
independently  by  saving  the  display  in  a  file  and  running  the 
program  HCOPY .SAV. 

FREQUENCY  DOMAIN  -  This  option  is  available  with  the  individual  channel 

output  waveforms  only.  It  chains  to  a  program  developed 
to  plot  the  FFT  of  the  display  in  either  polar  or  rec¬ 
tangular  form.  The  FFT  program  is  then  chained  back  to 
the  individual  channel  output  waveform  program. 

EXIT  -  This  mmand  is  only  an  exit  command  as  far  as  the  command  mode  is 
concerned.  If  the  individual  plot  mode  was  selected,  then  at  this 
time  this  program  would  return  and  ask  the  user  if  he  wished  to  view 
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any  other  individual  plot.  In  the  simultaneous  plot  mode  the  program 
would  exit  this  program  and  chain  with  the  simulator  driver. 

5.2  GRAPHICS  LIBRARY  : 

The  diversity  of  the  types  of  plots  needed  for  the  ICS  mandated  that 
the  plotting  routines  be  as  modular  as  possible.  For  this  reason  twenty-two 
separate  subroutines  were  developed.  Each  subroutine  serves  a  specific  pur¬ 
pose  and  can  be  readily  applied  to  particular  applications. 

It  is  well  worth  noting  that  because  of  the  general  nature  of  these 
subroutines  they  may  be  utilized  in  developing  plotting  capabilities  for  any 
system  of  moderate  complexity. 

For  ease  of  understanding  we  list  each  subroutine,  define  its  variables, 
and  give  a  description  of  its  function  and  algorithmic  implementation. 
Listings  can  be  found  in  [253 • 

Subroutine  LHIT 

IHD  -  The  number  of  the  menu  item  selected. 

ISTART  -  The  number  of  the  subpicture  tag  corresponding  to  the  first  menu 
i  tern. 

INUM  -  The  number  of  items  in  the  menu. 

The  purpose  of  this  subroutine  is  to  service  a  user  specified  menu  by 
waiting  for  a  light  pen  hit.  The  subroutine  returns  the  number  of  the  menu 
item  selected. 

Subroutine  ZINIT 

IXORG  -  X-axis  origin  in  Raster's. 

IYORG  -  Y-axis  origin  in  Raster's. 
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This  routine  inserts  the  coordinates  system  origin  into  the  oosmon  block 
SCFILE .  The  input  is  in  Raster's;  the  program  merely  transfers  these  values 
into  the  common  block. 

Subroutine  ZMMAX 

ARRAY  -  Array  containing  data  points. 

NPTS  -  Number  of  points  in  ARRAY. 

INC  -  Incremental  value  for  points  to  be  considered. 

SMAX  -  Value  returned  by  subroutine  as  maximum  in  ARRAY. 

SMIN  -  Value  returned  by  subroutine  as  minimum  in  ARRAY. 

IND  -  Dummy  variable. 

This  routine  scans  a  user  specified  array  and  determines  the  largest 
and  smallest  values  in  the  array.  The  routine  will  only  consider  every 
INC-number  of  points;  thus  to  consider  every  point  in  the  array  a  one 
should  be  entered. 

Subroutine  ZCNR 

RN  -  Real  number  to  be  converted  into  raster  units. 

R  -  Raster  equivalent  of  input. 

IWHO  -  Identifies  the  appropriate  axis 
IWH0=1  then  X-axis. 

IWHO=0  then  Y-axis. 

The  purpose  of  this  subroutine  is  to  convert  real  numbers  into  raster 
units.  This  is  done  by  obtaining  the  scale  factor  for  the  appropriate  axis 
and  normalizing  the  number  to  the  appropriate  boundary. 


Subroutine  ZCRN 


RN  -  Real  number  equivalent • of  input . 

R  -  Raster  number  to  be  converted  into  a  real  number. 

IWHO  -  Identifies  the  appropriate  axis. 

IWH0=1  then  X-axis. 

IWH0=0  then  Y-axis. 

This  subroutine  scales  the  appropriate  axis  by  taking  the  maximum  and 
minimum  values,  converting  these  to  Raster's  (see  subroutine  ZCRN),  deter¬ 
mining  the  difference,  and  then  dividing  by  the  axial  length.  These  values 
are  then  stored  in  the  common  block  SCFILE. 

Subroutine  ZSCALE 

ARRAY  -  Array  containing  data  points. 

NPTS  -  Number  of  data  points  in  array  to  be  considered. 

1AXL  -  Axis  length  in  Raster  units. 

INC  -  Increment  value  of  array  to  be  considered. 

IWHO  -  Identifies  the  appropriate  axis. 

IWH0=1  then  X-axis. 

IWHO=0  then  Y-axis . 

The  purpose  of  this  subroutine  is  to  determine  the  scale  factor  for  the 
appropriate  axis.  This  differs  from  subroutine  ZQSCAL  in  that  for  this  sub¬ 
routine  the  actual  array  and  number  of  points  are  input.  In  subroutine 
ZQSCAL  the  maximum  and  minimum  values  are  entered  whereas  here  they  are 
determined . 
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Subroutine  ZLSCAL 


ARRAY  -  Array  containing  data  points. 

NPTS  -  Number  of  points  in  array  to  be  plotted. 

IAXL  -  Axis  length  in  Raster  units. 

INC  -  Increment  value  of  array  to  be  considered. 

IWHO  -  Identifies  the  appropriate  axis. 

IWH0=1  then  X-axis. 

IWHO=0  then  Y-axis . 

This  subroutine  determines  the  scale  factors  for  a  logarithm  plot.  This 
program  invokes  subroutine  ZTENSO  to  determine  the  boundary  values.  Then 
subroutine  ZQSCAL  is  called  to  determimine  the  scale  factors  to  be  inserted 
into  the  common  block  SCFILL. 

Subroutine  ZYAXIS 

LABEL  -  ASCII  character  string  label  for  Y-axis . 

Maximum=20  characters  (including  blanks) 

NCHAR  -  Number  of  characters  in  LABEL. 

IPER  -  Number  of  decimal  places  on  values  on  Y-axis. 

The  purpose  of  this  subroutine  is  to  draw  a  linear  Y-axis  on  the  screen. 
This  is  done  by  recalling  the  values  in  the  common  block  SCFILE.  Placement 
of  the  label  is  made  on  the  basis  of  the  axis  boundaries. 

Subroutine  ZLYAX 

LABEL  -  ASCII  character  string  label  for  Y-axis. 

Maximum*20  (including  blanks) 

NCHAR  -  Number  of  characters  in  LABEL. 
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The  purpose  of  this  subroutine  is  to  draw  a  logarithmic  Y-axis  on  the 
screen.  This  is  done  by  recalling  the  values  in  the  common  block  SCFILE. 
Placement  of  the  label  is  made  on  the  basis  of  the  axis  boundaries. 

Subroutine  2XAXIS 

LABEL  -  ASCII  character  string  label  for  X-axis. 

Maximum=20  (including  blanks ) 

NCHAR  -  Number  of  characters  in  LABEL. 

I PER  -  Number  of  decimal  places  on  values  on  X-axis. 

INUM  -  Flag  to  indicate  whether  or  not  to  print  the  LABEL 
INUM*=0  then  do  not  print  the  LABEL. 

INUM=1  then  print  the  LABEL. 

This  subroutine  draws  out  a  linear  X-axis  on  the  basis  of  the  Tna-vimm. 
and  minimum  values  in  an  array.  Using  the  scale  factors  it  will  continue 
to  draw  vertical  lines  until  such  time  that  the  spacing  between  the  lines 
is  less  than  75  Raster  units.  (This  distance  may  be  changed  g  line  51  of 
this  routine.) 

Subroutine  ZHOLD 

ARRAY  -  Array  containing  data  points. 

NPTS  -  Number  of  points  to  be  plotted. 

IDX  -  X-axis  increment. 

This  subroutine  is  used  to  plot  binary  data.  It  will  maintain  either 
a  one  or  a  zero  for  IDX  number  of  points.  When  utilizing  this  subroutine 
it  must  be  remembered  that  IDX  is  the  number  of  points  to  be  tracked,  and 
not  the  number  of  changes  to  be  recorded. 
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Subroutine  ZDATA 


YARA  -  Array  containing  Y-axis  data. 

NPTS  -  Number  of  points  in  YARA. 

INC  -  Increment  value  of  array  to  be  considered. 

INT  -  Intensity  of  data  points  and  interconnecting  lines. 

IFL  -  Flashing  parameter  for  data  points. 

ITYPR  -  Type  of  lines  to  be  printed  to  connect  the  points. 

This  subroutine  connects  YARA  data  points.  There  is  an  underlying 
assumption  that  these  points  are  evenly  spaced  relative  to  the  X-axis. 

The  program  calls  the  subroutine  ZCRN  and  converts  the  data  to  Raster  units. 
The  increment  value  for  the  X-axis  is  determined  by  the  difference  between  the 
first  two  points  and  a  line  is  drawn  between  these  two  points.  The  procedure 
continues  until  all  the  points  have  been  processed. 

Subroutine  ZSDATA 

XARA  -  Array  containing  X-axis  data. 

YARA  -  Array  containing  Y-axis  data. 

NPTS  -  Number  of  points  in  XARA  and  YARA. 

INC  -  Increment  value  of  array  to  be  considered. 

ICKAR  -  Character  type 
ICHAR=1  then  'X' . 

1CHAR=2  then  'I'. 

1CHAR=3  then 
ICHAR=i*  then  'C'. 

This  subroutine  plots  a  character  at  the  data  points.  It  will  not  draw 
interconnecting  lines  between  these  points. 

81 


,^4^1 


Subroutine  ZDATA1 


XARA  -  Array  containing  X-axis  data. 

YARA  -  Array  containing  Y-axis  data. 

NPTS  -  Number  of  points  in  XARA  and  Yara. 

INC  -  Incremental  value  of  array  to  be  considered. 

INT-  Intensity  of  data  points  and  interconnecting  lines. 

IFL  -  Flashing  parameter  for  data  points. 

ITYPR  -  Type  of  lines  to  be  printed  to  connect  the  points. 

This  subroutine  will  plot  and  connect  points  with  non-constant  incremental 
X-axis  values.  The  program  reads  in  the  coordinates  for  the  first  point; 
on  the  basis  of  the  scale  factors  and  the  boundary  conditions  located  in 
the  common  block  SCFILE,  it  plots  the  point. 

Subroutine  ZSAVE 

The  purpose  of  this  subroutine  is  to  save  a  graphical  display  on  the  disc 
for  later  viewing.  The  subroutine  requests  a  name  for  the  display;  a  name 
of  the  form  "RK1 : XXXXXX  -PIC"  is  entered  where  XXXXXX  is  a  user  specified 
name  of  no  more  than  six  characters. 

Subroutine  ZSDEC 

ARRAY  -  Array  containing  data  points. 

NPTS  -  Number  of  points  in  array. 

IAXL  -  Axial  length  in  Raster  units. 

INC  -  Incremental  value  of  data  to  be  considered. 

IWHC  -  Identifies  the  appropriate  axis. 

IWH0*1  then  X-axis. 

IWH0=0  then  Y  axis. 
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This  subroutine  sets  up  a  decibel  scale  on  the  specified  axis.  By  con¬ 
verting  ARRAY  into  decibels  and  then  converting  these  into  Raster  units,  we 
are  able  to  determine  the  scale  factor.  These  values  are  then  stored  in  the 
common  block  SCFILE. 

Subroutine  ZNMBER 

VAL  -  Number  to  be  printed. 

IPREC  -  Number  of  numbers  to  follow  decimal  point, 
i.e.  degree  of  accuracy 

This  subroutine  is  used  to  place  the  user  defined  degree  of  accuracy 
on  the  screen.  The  user  specifies  IPREC-digits  to  follow  the  decimal  point, 
the  routine  calls  the  system  function  'ENCODE'  and  it  is  placed  on  the 
screen  as  an  axis  label. 

Subroutine  ZAUTOF 


VAL  -  Number  to  be  formatted. 

IFOR  -  Format  type  for  VAL. 

NFRM  -  Field  length  of  IFOR  for  VAL. 

IPREC  -  Number  of  numbers  to  follow  decimal  point, 
i.e.  degree  of  accuracy. 

This  routine  given  that  VAL  is  to  be  printed  on  the  screen  with  IPREC 
degree  of  accuracy  will  determine  the  format  type  of  VAL  and  the  field  length 
required.  By  searching  VAL  and  determining  the  location  of  the  decimal  point 
the  routine  then  decides  on  whether  to  label  it  INTEGER,  FLOATING,  or  GENERAL. 
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Subroutine  WAIT 


OHM  -  A  relative  indicator  of  the  length  of  time  for  the  system  to  halt. 

This  routine  performs  a  predetermined  computation  (200)*(IHUM)  times. 

It  will  perform  the  computation  and  then  return  to  the  calling  routine. 

Subroutine  TRACK 

This  subroutine  is  used  for  documenting  graphs  on  the  screen.  A  set 
of  options  are  made  available  through  this  routine  directly.  For  example, 

he  may  draw  a  line  on  the  screen,;  he  may  input  characters  on  the  screen 
in  either  a  vertical  or  horizontal  direction.  The  positioning  of  every¬ 
thing  is  done  with  the  use  of  the  light  pen  and  the  tracking  object. 

Common  Block  SCFILE 

Since  this  common  block  appears  in  nearly  all  of  the  packages  subroutine, 
an  explanation  of  its  content  is  in  order. 

ZXSF  -  X-axis  scale  factor. 

ZYSF  -  Y-axis  scale  factor. 

ZXORG  -  X-axis  origin  in  Raster's. 

ZYORG  -  Y-axis  origin  in  Raster's. 

ZXMAX  -  Maximum  X-axis  value  in  Raster's. 

ZYMAX  -  Maximum  Y-axis  value  in  Raster's. 

ZRXMDl  -  Minimum  X-axis  value  in  real  numbers. 

ZRYMUT  -  Minimum  Y-axiB  value  in  real  numbers. 
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6.0  FUTURE  ICS  ENHANCEMENTS  : 


Upon  review  of  the  present  status  and  capabilities  of  the  Interactive 
Communications  Simulator  (ICS)  there  are  several  obvious  directions  in  which 
♦his  system  could  be  updated.  The  following  is  a  partial  list  of  several  of 
the  more  straightforward  extensions: 

1. )  Source  Coding:  At  present  the  ICS  includes  a  binary  memoryless  source 

producing  equiprobable  symbols.  Since  the  ultimate  goal  of  many  digital 
communications  systems  is  to  provide  a  transmission  capability  for 
analog  sources,  it  is  of  some  interest  to  consider  the  addition  of  a 
source  coding  capability.  We  list  here  several  options  which  could 
easily  be  provided. 

a.  )  PCM/DPCM  including  delta  modulation. 

b. )  Block  transform  coding  using  various  unitary  transforms. 

c. )  Tree-encoding  schemes  which  offer  the  potential  of  performance 

approaching  the  rate- distort ion  bound. 

d.  )  Minimum  mean-square  coding  concepts. 

2.  )  Spread-Spectrum  Capability:  The  existing  channel  model  incorporated  into 

the  ICS  consists  of  a  three- component  fading-dispersive  channel  with 
an  impulsive  noise  capability.  It  would  be  of  some  interest  to  provide 
the  ability  to  simulate  spread-spectrum  modulation  under  various  inter¬ 
ference  or  jamming  conditions.  Specifically,  it  would  be  possible  to 
simulate  direct  sequence  (DS)  or  frequency-hopped  (FH)  modulation  by 
PN  sequences.  The  various  interference  or  Jamming  conditions  could  be 
appropriately  modeled  as  finite-state  burst  channels. 

3.  )  Explicit  Diversity:  At  present  we  can  simulate  a  single  fading-dispersive 

channel.  It  would  be  of  significant  utility  if  a  multichannel  capability 
were  provided.  This  would  be  useful,  in  particular,  for  modulation/ 
coding  studies. 
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1*. )  Spectrum  Efficient  Modulation:  The  ICS  presently  includes  a  number  of 
classical  modulation  strategies  such  as  BPSK,  QPSK,  OQPSK,  MSK,  etc. 
While  relatively  efficient  on  the  basis  of  symbol  error  probability 


for  a  given  expenditure  of  K^/N^,  these  modulation  strategies  are 
not  necessarily  efficient  in  terms  of  spectral  occupancy.  There  is 
presently  a  great  deal  of  interest  in  the  use  of  combined  amplitude/ 
phase  coding  techniques  which  offer  bandwidth  efficiencies  in  excess 
of  2  bits/sec/Hz.  It  would  be  relatively  easy  to  include  such  modu¬ 
lation  strategies  in  the  ICS.  Indeed,  it  would  be  possible  to  allow 
the  user  freedom  to  choose  quite  arbitrary  signaling  constellations 
in  amplitude/phase  space. 

5*)  Cross-Polarization  Interference:  In  an  effort  to  improve  bandwidth, 
efficiency  of  microwave  line-of-sight  (LOS)  digital  radio  systems 
use  of  independent  cross-polarized  transmission  channels  have  been 
used.  Unfortunately,  non-ideal  propagation  conditions  result  in 
mutual  or  co-channel  interference  which  significantly  degrades 
performance.  These  propagation  induced  interference  effects  could 
he  realistically  and  flexibly  simulated  in  the  ICS. 

6.  )  Adaptive  Nulling:  A  wide  variety  of  future  military  communication  systems 

will  make  use  of  adaptive  array  nulling  systems  of  one  form  or  another. 
Unfortunately,  the  dynamic  effects  of  these  nulling  systems  can  have 
a  profound  influence  on  communication  system  performance.  These 
effects  are  often  not  amenable  to  analytical  evaluation.  It  would 
he  of  some  interest,  then,  to  provide  the  capability  of  simulating 
these  effects  within  the  ICS  and  thus  provide  explicit  means  for 
evaluating  the  effects  on  communication  system  performance. 

7. )  Performance  Monitoring:  Future  military  communication  systems  will 

undoubtedly  be  provided  with  some  form  of  performance  monitoring 
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capability  to  predict  link  outages  and/or  reliability.  Many  of  the 
more  promising  performance  monitoring  techniques  have  not  been  eval¬ 
uated  in  a  realistic  communications  environment.  This  could  readily 
be  accomplished  by  incorporating  performance  monitoring  techniques 
into  the  ICS. 

8.  )  Nonlinear  Receivers:  The  existing  ICS  has  a  fairly  extensive  impulse 

noise  simulation  capability.  The  receiver  structures  for  tne  various 
modulation  capabilities  are  invariably  linear.  These  receiver  struc¬ 
tures  suffer  drastically  from  the  effects  of  impulse  noise.  Various 
non-linear  receiver  structures  of  the  limiting  variety  have  been  used 
to  mitigate  these  effects.  Several  of  these  non-linear  structures  have 
been  included  in  the  ICS.  It  would  be  a  relatively  simple  matter  to 
incorporate  a  wider  range  of  nonlinear  receivers  into  the  ICS.  This 
would  be  extremely  useful  in  evaluating  modulation/coding  concepts 
in  impulsive  noise  environments. 

9.  )  Adaptive  Equalization:  The  ICS  has  a  variety  of  fixed  equalizer 

capabilities.  At  present,  we  utilize  a  "cheater"  line  to  tell 

the  equalizer  what  tne  channel  structure  is.  In  practice  this  should 
be  automatic.  That  is,  the  equalizer  should  acquire  and  track  the 
unknown  channel  parameters.  It  is  proposed,  then,  that  a  truly 
adaptive  equalizer  capability  be  provided  as  part  of  any  future  up¬ 
grading  of  the  ICS. 

10. )  Optimum  Receiver  Structures  in  AWGN:  In  addition  to  data  demodulation, 
various  ancillary  functions  such  as  equalization,  phase/timing 
synchronization,  etc.,  must  be  accomplished  in  typical  receiver  module. 
On  the  AWGN  channel,  linear  matched  filter  outputs  sampled  at  the  baud 
rate  provide  sufficient  statistics  for  accomplishing  this.  More  general 
receiver  structures  could  easily  be  provided  in  the  ICS  to  allow 


flexible  simulation  of  optimum  receivers.  This  would  allow  use  of 
the  ICS  as  a  test-bed  for  exploring  new  modem  concepts. 

11.  )  Optimum  Receiver  Structures  for  Impulsive  and/or  Fading-Dispersive  Channels: 

Little  work  has  been  done  in  characterizing  the  structure  and  performance 
of  optimum  receivers  for  impulsive  and/or  fading-dispersive  channels. 

On  the  basis  of  recent  work  in  this  area  it  would  be  a  relatively 
straightforward  task  to  provide  simulation  modules  for  fairly  general 
optimum  structures  in  the  ICS.  This  would  allow  investigation  of 
various  suboptimum  structures  which  approximate  optimum  and  presumably 
more  complex  receivers. 

12.  )  Channel  Coding/Decoding:  There  are  several  directions  in  which  the  channel 

coding/decoding  capabilities  could  be  upgraded.  We  list  several  obvious 
directions : 

a.  )  Additional  binary  block  codes  and  associated  decoders. 

b. )  Provide  a  concatenated  coding/decoding  capability. 

c. )  Implement  Chase's  soft-decision  decoding  algorithm. 

d.  )  Provide  a  sequential  decoding  capability. 

13. )  Improved  Graphics:  The  interactive  computer  graphics  provided  with  the 

ICS  is  in  a  constant  state  of  evolution.  There  are  always  some 
things  that  can  he  added  to  enhance  and  otherwise  improve  the  oper¬ 
ation  of  the  ICS.  We  mention  a  few: 

a.  )  Provide  additional  capabilities  for  plotting  and  displaying 

error  statistics. 

b.  )  Provide  3-D  plotting  capabilities  for  scattering  functions, 

2-D  histograms  of  phase  and  hit  timing  errors,  etc. 

c. )  Provide  capabilities  for  computation  and  display  of  amplitude 

probability  distributions  (APD's)  of  noise  waveforms. 

d.  )  Allow  plotting  and  display  of  eye- diagrams  showing  the  effects 
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of  Intersymbol  Interference  (ISI). 

e.  )  Improved  waveform  plotting  capabilities  in  both  the  time  and 

frequency  domain. 

f .  )  Provide  software  improvements  to  enhance  computational  speed. 
lU.)  Karrowband  Filtering:  At  present  the  ICS  possesses  an  infinite  impulse 

response  (HR)  narrowband  filtering  capability.  The  design  procedure 
employed  allows  control  over  magnitude  response  but  not  phase  response. 

It  would  be  of  some  interest  to  provide  a  finite  impulse  response 
(FIR)  capability  as  well.  This  would  allow  control  over  both  magni¬ 
tude  and  phase  response  and  thus  provide  added  flexibility. 

15- )  Interleaving  Capability:  With  the  addition  of  expanded  data  memory  it 

would  be  a  relatively  simple  matter  to  provide  an  interleaving  capability. 
This  should  include  both  block  and  convolutional  interleaving  capabilities. 
6.1  HARDWARE  IMPROVEMENTS: 

In  order  to  implement  many  of  the  suggested  enhancements  indicated  above, 
consideration  should  be  given  to  simultaneous  hardware  improvements.  At 
the  very  least  this  should  include: 

1. )  Program  Source  Memory:  Should  be  increased  from  present  IK  to  1.5-2K 

This  will  allow  increased  efficiency/throughput  for  ICS. 

2.  )  Data  Memory.  Should  be  increased  from  present  l6iK  to  32K.  This 

would  allow  explicit  diversity  and/or  interleaving  capability. 

3  .)  Graphics  Terminal:  The  existing  VT-11  terminal  should  'be  replaced 
by  a  higher  resolution  CRT  with  improved  writing  speed  and  graphics 
support  software. 

U.)  Real-Time  Interface:  The  real-time  interface  being  installed  on  the 
AP-120B  should  allow  interface  of  the  ICS  to  real  channels.  This 
possibility  should  be  explored. 


89 


References 


1.  J".  P.  Odenw&lder,  "Optimum  Decoding  of  Convolutional  Codes",  Ph.D.  Dissert¬ 
ation,  Syst.  Sci.  Dept.,  Univ.  California,  Los  Angeles,  1970. 

2.  K.  J.  Larsen,  "Short  Convolutional  Codes  with  Maximal  Free  Distance  for 

Rates  1/2,  1/3  and  1/U",  IEEE  Trans.  Inform.Theory,  Vol.IT -19,  pp. 371-372, May  1973. 

3.  W.  C.  Linsey  and  M.  K.  Simon,  Telecommunication  Systems  Engineering.  Prentice- 
Hall,  Englewood  Cliffs,  N.  J. ,  1973 

1*.  J.  J.  Spilker,  Jr.,  Digital  Communications  by  Satellite,  Prentice-Hall, 

Englewood  Cliffs,  N.J. ,  1977. 

5.  P.  A.  Bello,  "Characterization  of  Randomly  Time-Variant  Linear  Channels", 

IEEE  Trans.  Commun.  Syst.;Vol.  CS-11,  pp.  360-393,  Dec.  1963- 

6.  R.  S.  Kennedy,  Fading  Dispersive  Communication  Channels,  Wiley-Interscience, 

New  York,  1969* 

7.  J.  W.  Modestino  and  B.  Sankur,  "Modeling  and  Simulation  of  ELF/VLF  Noise", 

Proc.  Seventh  Annual  Pittsburgh  Conf.  on  Modeling  and  Simulation,  Pittsburgh, 

PA.,  pp.l89-19L,  April  1976. 

8.  J.  W.  Modestino  and  B.  Sankur,  "Modeling  and  Analysis  of  Inqpulsive  Noise", 

Proc.  of  NATO  Conf.  on  Communication  and  Signal  Processing,  Darlington, 

England,  pp.  619-636,  Aug.  1977. 

9.  G.  D.  Forney,  Jr. ,  "Maximum-Likelihood  Sequence  Estimation  of  Digital 
Sequences  in  the  Presence  of  Intersymbol  Interference" ,  IEEE  Trans. 

Information  Theory,  Vol.  IT-l8,  pp.  363-377,  May  1972. 

10.  J.  G.  Proakis,  "Advances  in  Equalization  of  Intersymbol  Interference", 

Chapt.  3  in  Advances  in  Communication,  Ed.  by  A.  J.  Viterbi,  Prentice-Hall, 
Englewood  Cliffs ,  H.J.,  1975- 

11.  P.  Monsen,  "Feedback  Equalization  for  Fading  Dispersive  Channels”,  IEEE 
Trans.  Inform.  Theory,  Vol.  IT-17,  pp.  56-6L,  Jan.  1971 

12.  P.  Monsen,  "Digital  Transmission  Performance  on  Fading  Dispersive  Diversity 
Channels",  IEEE  Trans,  on  Commun.,  Vol.  COM-21,  pp.  33-39,  Jan.  1973. 

13.  P-  Monsen,  "Theoretical  and  Measured  Performance  of  a  DFE  Modem  on  a  Fading 
Multipath  Channel",  IEEE  Trans,  on  Commun.,  Vol.  COM-25,  PP-  111*9-1153,  Oct. 1971. 

ll*.  A.  J.  Viterbi,  "Convolutional  Codes  and  Their  Performance  in  Communication 
Systems",  IEEE  Trans.  Commun.  Tech.,  Vol.  COM- 19,  pp.  751-772,  Oct.  1971. 

15.  G.  D.  Forney,  Jr.,  "The  Viterbi  Algorithm",  Proc.  of  IEEE,  Vol.  6l,  pp.  268- 
278,  March  1973- 

16.  J.  K.  Wolf,  "Efficient  Maximum  Likelihood  Decoding  of  Linear  Block  Codes 
Using  a  Trellis",  IEEE  Trans.  Inform.  Theory,  Vol.  IT -2h,  pp.  76-81,  Jan.  1978. 


90 


17.  J.  A.  Heller  and  I.  M.  Jacobs,  "Viterbi  Decoding  for  Satellite  and  Space 
Communication,"  IEEE  Trans.  Commun.  Tech.,  Vol.  COM-19,  pp.  835-8^8, 

Oct.  1971. 

18.  J.  W.  Modestino,  "Error  Probability  Bounds  for  Soft-Decision  Decoding  of 
Black  Codes,"  TM  78-30,  unpublished  RPI  report,  Nov.  1978. 

19.  D.  G.  Daut,  J.  W.  Modestino,  and  L.  D.  Wismer,"Nev  Short  Constraint  Length 
Convolutional  Code  Constructions  for  Selected  Rational  Rates",  submitted 
to  IEEE  Trans,  on  Inform.  Theory. 

20.  K.  R.  Matis  and  J.  W.  Modestino,  "Reduced-State  Soft  Decision  Trellis 
Decoding  of  Linear  Block  Codes",  submitted  to  IEEE  Trans,  on  Inform. Theory. 

21.  AP-120B  Programmer's  Reference  Manual. 

22.  RPI  Technical  Memo  TM78-17. 

23-  AP-120B  Internal  Interface  Manual. 

2k.  PDP-11 /U0,  RT-11  Systems  Reference  Manual. 

25.  T.  T.  Murakami ,  "The  Design  and  Analysis  Stages  for  the  Interactive  Communi¬ 
cations  Simulator",  M.S.  Thesis,  ESE  Dept.,  Rensselaer  Polytechnic  Institute, 
Troy,  N.  Y. ,  July  1979- 

26.  E.  Godreau,  III,  "Interactive  Graphics  Support  for  the  Communications  Simu¬ 
lator",  Project  Report,  ESE  Dept.,  Rensselaer  Polytechnic  Institute,  Troy, 
N.Y.,  June  1980. 


i 


i 


MISSION 

of 

Rome  Air  Development  Center 


RAPC  plans  and  execute*  research,  development,  test  and 
selected  acquisition  programs  in  Support  of  Command,  Control 
Communications  and  Intelligence  [CH)  activities.  Technical 
and  engineering  support  uUthin  areas  of  technical  competence 
is  provided  to  ESP  Program  OUie.es  IPOs)  and  other  ESP 
elements.  The  principal  technical  mission  areas  are 
communications,  electromagnetic  guidance  and  control,  sur¬ 
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